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Indian Standard
INFORMATION TECHNOLOGY TELECOMMUNICATIONS AND INFORMATION EXCHANGE BETWEEN SYSTEMS-OPEN SYSTEMS INTERCONNECTION - PROTOCOL FOR PROVIDING THE CONNECTION - MODE TRANSPORT SERVICE
NATIONAL FOREWORD This Indian Standard which is identical with IS0 8073:1992 `Information technology -Telecommunications and Protocol for providing the connection information exchagne between systems-Open systems interconnection- mode transport sevice', issued by the International Organization for Standardization (ISO) was adopted by the Bureau of Indian Standards on the recommenation of Computer Systems and Interconnection Sectional Committee (LTD 36) and approval of the Electronics and Telecommunication Division Council. In the adopted standard certain terminology and conventions are however not identical to those used in Indian Standards. Attention is particularly drawn to the following: Where the words `International Standard'appear referring to this standard, they should be read as'lndian Standard'.

In this Indian Standard, the following International Standards are referred to.Read in their respective place the following: International Standard IS0 7498 : 1984 Information processing system -Open systems interconnection - Basic reference model Corresponding Indian Standard Degree of Equivalence Identical

IS 12373 (Part 1) : 1987 Basic reference model of open systems interconnectionforinformationprocessingsysterns: Part 1 IS 12373 (Part3) : 1992 Basic reference model of open systems interconnection processing systems : Part 3 Naming and addressing IS 13589:1993 Transport service definition in open systems interconnection for information processing systems IS 13868 : 1994 Network service definition in data communication for information processing systems

IS0 7498-3 : 1989 Information processing systems-Open systems interconnection - Basic reference model Part 3: Naming and addressing IS0 8072 : 1986 Information processing systems-Open systems interconnection -Transport service definition ISOilEC 8348:1992 Information processing systems - Data communications - Network service definition

Identical

Identical

Identical

Thetechnicalcommitteeresponsibleforthepreparation ofthisstandard has reviewedtheprovisionsofthefollowing IS0 Standards and has decided that they are acceptable for use in conjunction with this standard: ISO/IEC 11570:1992 Information technology - Telecommunications and information exchange between systems - Open systems interconnection - Transport protocol identification mechanism. CCITT X. 224 Transport protocol specification for open systems interconnections for CClll version 1988. 3 Applications,
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1

Scope
Standard specifies over the

This International

These procedures are applicable to instances of communication between systems which support the Transport Layer of the OSI Reference Model and which wish to interconnect in an open systems environment. This International Standard specifies, in clause 14, conformance requirements for systems implementing these procedures and provides the PIGS proforma in compliance with the relevanf requirements, and in accordance with the relevant guidance, given in ISO/IEC 9646-2. It does not contain tests which can be used to demonstrate this conformance.

a) five classes of procedures when operating connection-mode network service: 1) class 0: simple class; 2) class 1: basic error recovery 3) class 2: multiplexing class; and multiplexing and recovery class;

4) class 3: error recovery 5) class 4: error detection

class;

class;

2
for the connection-mode transfer of data and control information from one transport entity to a peer transport entity; b) one class (class 4) of procedure when operating the connectionless-mode network service; c) the means of negotiating the class of procedures be used by the transport entities; over

Normative

references

to

The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and IS0 maintain registers of currently valid International Standards. IS0 7498:1984, lnformafion processing systems Systems Interconnection -Basic Rererence Model. Open

d) the structure and encoding of the transport protocol data units used for the transfer of data and control information. The procedures are defined in terms of

a) the interactions between peer transport entities through the exchange of transport protocol data units; b) the interactions between a transport entity and the transport service user in the same system through the exchange of transport service primitives; c) the interactions between a transport entity and the network service provider through the exchange of network service primitives. These procedures are defined in the main text of this International Standard supplemented by state tables in annex A.

IS0 7498:!984/Add.!:i987, Information processing systems - Open Systems Interconnection - Basic Reference Model - Addendum !: Conr?ectionless-mode transmission. !SO 7498-3:1989, Information processing systems - Open Systems Intercor/nection - Basic Reference Model - Parr 3: Naming and addressing. IS0 8072:1986, Information processing systems - Open Systems interconnection - Transport service definition. ISO/IEC 8348:1992, Data communications Information - Network processing systems service definition. -
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ISOAEC 9646-1 :lQQl, Information technology - Open Systems Interconnection Conformance testing methodology and framework - Part 1: General concepts. ISO/IEC 9646-2:1991, information technology Systems Interconnection Conformance methodology and framework - Part 2: Abstract specification. Open testing test suite -

Information technology ISOAEC 11570:1992, Telecommunications and information exchange between systems Open Systems Interconnection Transport protocol identification mechanism. CCIPT X.224, Transport Systems Interconnection 1988. Protocol Specification for CCITT Applications for Open Version
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Section one: General

3

Definitions
in this clause make use of

3.2.8 receiving transport that receives a given TPDU.

entity:

A transport

entity

NOTE - The definitions contained abbreviations defined in clause 4.

.

3.1 This International Standard is based on the concepts developed in IS0 7498 and IS0 7498iAdd.l and ISO/IEC 7498-3 and makes use of the following terms defined in it:
a) concatenation b) segmenting c) multiplexing and separation; and reassembling; and demultiplexing;

3.2.9 preferred class: The protocol class that the initiator indicates in a CR TPDU as its first choice for use over the transport connection. alternative class: A protocol class that the 3.2.10 initiator indicates in a CR TPDU as an alternative choice for use over the transport connection. proposed 3.2.11 alternative class. class: A preferred class or an

d) splitting

and recombining;

The protocol class that the 3.2.12 selected class: responder indicates in a CC TPDU that it has chosen for use over the transport connection. proposed parameter: The value for a parameter 3.2.13 that the initiator indicates in a CR TPDU that it wishes to use over the transport connection. selected parameter: The value for a parameter 3.2.14 that the responder indicates in a CC TPDU that it has chosen for use over the transport connection. error indication: 3.2.15 N-DISCONNECT indication an error, that a transport provider. An N-RESET indication, or an with a reason code indicating entity receives from the NS-

e) flow control; f) connectionless-mode value. Standard, the transmission:

g) nil selector

3.2 For the purposes of this International following definitions apply:

Hardware or software or a equipment: 3.2.1 combination of both; it need not be physically distinct within a computer system. An abstract transport service user: 3.2.2 representation of the totality of those entities within a single system that make use of the transport service. network service provider: An abstract machine 3.2.3 that models the totality of the entities providing the network service, as viewed by a transport entity. local matter: A decision made by a system 3.2.4 concerning its behavior in the Transport Layer that is not subject to the requirements of this protocol. 3.2.5 TPDU. initiator: A transport entity that initiates a CR

invalid TPDU: A TPDU that does not comply 3.2.16 with the requirements of this International Standard for structure and encoding. protocol error: 3.2.17 comply with the procedures 3.2.18 sequence A TPDU whose for the class. use does not

.

number:

a) the numb-r in the TPDU l~ti field of a DT TPDU that indicates the o-der in which the DT TPDU was transmitted `>y a transport entity; b) the number in the YR-TU-NR field of an AK or RJ TPDU that indicates the sequence number of the next DT TPDU expected to be received by a transport entity. The set of consecutive transmit window: 3.2.19 sequence numbers which a transport entity has been authorized by its peer entity to send at a given time on a given transport connection.

responder: A transport entity with whom 3.2.6 initiator wishes to establish a transport connection.

an

NOTE - Initiator and responder are defined with respect to a single
transport connection. A transport responder simultaneously. entity can be both an initiator and

sending transport 3.2.7 sends a given TPDU.

entity:

A transport

entity that
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3.2.20 number

lower window edge: in a transmit window.

The

lowest

sequence

4

Symbols

and abbreviations

4.1 upper window edge: The sequence number 3.2.21 which is one greater that the highest sequence number in the transmit window. upper window edge allocated to the peer 3.2.22 entity: The value that a transport entity communicates to its peer entity to be interpreted as its new Lpper window edge. closed window: 3.2.23 no sequence number. A !ransmit window that contains TPDU TSDU NSDU 4.2 CR CC DR DC DT ED AK EA RJ ER 4.3

Data units Transport-protocol-data-unit Transport-service-data-unit Network-service-data-unit Types of Transport TPDU TPDU TPDU TPDU TPDU TPDU TPDU TPDU TPDU TPDU Protocol data units

window information: Information contained in a 3.2.24 TPDU relating to the upper and the lower window edges. A reference that 3.2.25 frozen reference: available for assignment to a connection because requirements of 6.18. unassigned reference: 3.2.26 neither currently in use for identifying nor which is in a frozen state. is not of the

Connection request TPDU Connection confirm TPDU Disconnect request TPDU Disconnect confirm TPDU Data TPDU Expedited data TPDU Data acknowledge TPDU Expedited acknowledge TPDU Reject TPDU Error TPDU

TPDU Fields Length indicator (field) Credit (field) Transport-service:access-point (field) Destination~reference (field) Source reference (field) End of TSDU mark DT TPDU number (field) ED TPDU number (field) Sequence number response ED TPDU number response Request of acknowledgement variables

A reference that is a transport connection

LI CDT TSAP-ID DST-FIEF SRC-REF EOT TPDU-NR ED-TPDU-NR Y R-TU-NR YR-EDTU-NR ROA 4.4

identifier

TS-user data that transparent (data): 3.2.27 transferred intact between transport nntities and which unavailable for use by ihe transport enrlties.

is is

owner (of a network connection): The transport 3.2.28 entiry !ha: issued the N-CONNECT request leading to the creation of thai network connection. Only applicable when operating over the connection-mode network service. retained 3.2.29 retransmission acknowiedgement re?ransmission. TpDU: A TPDU that is subject to the and retention procedure or procedure and is available for possible `\ uses the following terms

(field) (field) mark

Times and associated

3.3 This lnternationai Srandard dsfined in ISO/IEC 8348: a) connection-mode b) connectionless-mode network

service

T7 N L I W JJR TWR TSI JS2
MLR n/l,,

network service uses the following terms

3.4 This International Standard defined in ISO/IEC 9646-l: a) PIGS proforma implementation

ELR ERL I? AL AR

Local retransmission time The maximum number of transmissions Time bound on reference and sequence number Inactivity time Window time Time to try reassignmentlresynchronization Time to wait for reassignment/resynchronization Supervisory timer 1 Supervisory timer 2 NSDU lifetime local-to-remote NSDU lifetime remote-to-local Expected maximum transit delay local-to-remote Expected maximum transit delay remote-to-local Persistence time Local acknowledgement time Remote acknowledgement time Local inactivity time Remote inactivity time

b) protocol (PIGS)

conformance

statement

`L If4
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4.5

Miscellaneous Transport-service user Transport-service-access-point Network serv$e provider Network-servne-access-point Quality 01 service Connectionless-mode network service Connection-mode network service

5.2

Service Assumed from the Network Layer

T&user TSAP !!3;rider QOS CLNS CONS

The protocol specified in this International Standard assumes the use of the Network Service defined in ISO/IEC
8348.

When operating over CONS, information is transferred to and from the NS-provider in the network service primitives listed in Table 2a). When operating over CLNS, information is transferred to and from the NS-provider in the network service primitives listed in table 2b).
NOTES 1 The parameters listed in Table 2a) are those in the current connection-mode network service (see ISOAEC 8348). 2 The parameters listed in table 2b) are those in the current connectionless-mode network service (see ISOAEC 8348). 3 The way the parameters are exchanged between the transport entity and the NS-provider is a local matter.

5

Overview of the Transport Protocol

NOTE-This overview is not exhaustive and has been provided for
guidance.

5.1

Service provided

by theTransport

Layer

The protocol specified in this International Standard supports the Transport Service defined in IS0 8072. Information is transferred to and from the TS-user in the transport service primitives listed in Table 1.

Table 1 -Transport Primitives

service

primitives

T-CONNECT

request indication TS-user data Responding address Quality of service Expedited data option TS-user-data TS-user-data TS-user-data

T-DISCONNECT T-DISCONNECT

indication request indication

TS-user-data Disconnect reason TS-user-data

9
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Table 2a) - Connection-mode Primitives N-CONNECT request

network

service

primitives Parameters WIXIYL! X X Y ; 2 X Y Y X Z X Y

WY X X

indication

N-CONNECT

response confirm

X X

I

Called address Calling address

Receipt confirmation selection Expedited data selection QOS parameter set NS-user-data Responding address Receipt confirmation selection

N-DATA N-DATA ACKNOWLEDGE N-EXPEDITED N-RESET DATA

request indication request indication request indication request indication response confirm request

X
X

Expedited data selection QOS parameter set NS-user-data N-user-data Confirmation request

Y Y X X
X Y Y NS-user-data Reason Originator Reason qeason VS-user-data desponding address 3riginator 3eason qS-user-data desponding address Y

; W

N-RESET N-DISCONNECT

X X

W Z Z W W Z Z

indication

X

Key:
W: X: Y: 2: The usage of this parameter is a local matter, e.g. for diagnostic or to decide whether to attempt resynchronization. The Transport Protocol assumes that this facility is provided in all networks. The Transport Protocol assumes that this facility is provided in some networks and a mechanism is provided optionally use the facility. The Transport Protocol does not use this parameter.

to

Table 2b) - Connectionless-mode Primitives

network

service

primitives WlXNh! X X X X

WY
X

Parameters Source address Destination address Quality of service NS-user-data Source address Destination address Quality of service NS-user-data
to attempt

X

; ::
resynchronization. is provided to

L

W: X: Y: Z:

The usage of this parameter is a local matter, e.g. for diagnostic or to decide whether The Transport Protocol assumes that this facility is provided in all networks. The Transport Protocol assumes that this facility is provided optionally use the facility. The Transport Protocol does not use this parameter. in some networks

and a mechanism
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5.3 5.3.1

Functions

of the Transport of functions

Layer

a) select the network service which best matches the requirement of the TS-user taking into account charges for various services (see 6.5); b) decide whether to multiplex multiple connections onto a single network connection operating over CONS (see 6.5); c) transport only when

Overview

The functions in the Transport Layer are those necessary to bridge the gap between the services available from the Network Layer and those to be offered to the TS-users. The functions enhancement optimization. in the Transport Layer are concerned with the of quality of service, including aspects of cost

establish the optimum TPDU size (see 6.5); upon

d) select the functions that will be operational entering the data transfer phase (see 6.5); e) map transport addresses onto network between

These functions are grouped below into those used at all times during a transport connection and those concerned with connection establishment, data transfer and release. NOTE -This International Standard does not include the following functions which are under consideration for inclusion in future
editions of this International Standard:

addresses; two different

f) provide a means to distinguish transport connections (see 6.5); g) transport h) exchange 5.3.1.3

of TS-user data (see 6.5); values of Inactivity timers (see 6.5).

4 encryption; b) accounting mechanisms; 4
status exchanges and monitoring of QOS;

Data transfer

d) blocking;

4 temporary release of network connections; 9 alternative checksum algorithm.
5.3.1.1 The following and options, connection: Functions used at all times

The purpose of data transfer is to permit duplex transmission of TSDUs between the two TS-users connected by the transport connection. This purpose is achieved by means of two-way simultaneous communication and by the following functions, some of which are used or not used in accordance with the result of the selection performed in connection establishment. a) concatenation and separation (see 6.4): a function used to collect several TPDUs into a single NSDU at the sending transport entity and to separate the TPDUs at the receiving transport entity; b) segmenting and reassembling (see 6.3): a function used to segment a single data TSDU into multiple TPDUs at the sending transport entity and to reassemble them into their original format at the receiving transport entity; c) splitting and recombining (see 6.23): a function allowing, only when operating over CONS, the simultaneous use of two or more network connections to support the same transport connection; d) flow control (see 6.16): a function used to regulate the flow of TPDUs between two transport entities on one transport connection; e) transport connection identification: a means to uniquely identify a transport connection between the pair of transport entities supporting the connection during the lifetime of the transport connection; 1) expedited data (see 6.11): a function used to bypass the flow control of normal data TPDU. Expedited data TPDU flow is controlled by separate flow control;

functions, depending upon the selected class are used at all times during a transport

a) transmission

of TPDUs (6.2 and 6.9);

b) multiplexing and demultiplexing (see 6.15): A function used only when operating over CONS to share a single network connection between two or more transport connections; c) error detections (see 6.10, 6.13 and 6.17): A function used to detect the loss, corruption, `duplication, misordering, or misdelivery of TPDUs; d) error recovery (see 6.12, 6.14, 6.18, 6.19, 6.20, 6.21, and 6.22): A function used to recover from detected and signalled errors. 5.3.1.2 Connection establishment

The purpose of connection establishment is to establish a transport connection between two TS-users. The following functions of the transport layer during this phase match the TS-users' requested quality of service with the services offered by the network layer:

11
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g) TSDU determine 5.3.1.4

delimiting (see 6.3): a function used the beginning and ending of a TSDU. Release

to

Network connection a) Type A: residual error rate (for example, disconnect or reset) and acceptable errors.

with acceptable not signalled by rate of signalled

The purpose of release (see 6.7 and 6.8) is to provide disconnection of the transport connection, regardless of the current activity. 5.4 54.1 Classes and options when operating over CONS

b) Type 6: Network connections with acceptable residual error rate (for example, not signalled by disconnect or reset) but unacceptable rate of signalled errors. c) Type C: Network residual error rate. connections with unacceptable

General Layer have been organized It is assumed that each transport entity is aware of the qua!ity of service provided by particular network connections. 5.4.4 Characteristics of class 0

The functions of the Transport into classes and options.

A class defines a set of functions. Options define those functions within a class which may or may not be used. This International Standard defines five classes of protocol:

Class 0 provides the simplest type of transport connection and is fully compatible with the CCITT Recommendation T.70 for teletex terminals. Class 0 has been designed connections. 5.4.5 Characteristics to be used with type A network

a) class 0: simple class; b) class 1: basic error recovery class; c) class 2: multiplexing class; and muftiplexing and recovery class;

of class 1 connection with minimal

d) class 3: error recovery e) class 4: error detection NOTES

Class 1 provides overheads.

a basic transport

class. The main purpose of the class is to recover disconnect or reset. from network

1 Transport connections of classes 2,3 and 4 may be multiplexed together onto the same network connection.
2

Classes 0 to 3 do not specify mechanisms to detect unsignalled network transmission ft;ilcres. Negotiation

Selection of this class is usually based on reliability criteria. Class 1 has been designed to be used with type 6 network connections. 5.4.6 Characteristics General of class 2

5.4.2

5.4.6.1 The use of classes and options connection establishment. The transport entities will depend upon a) the TS-users' requirements CONNECT service primitives; b) the quality of the available is negotiated choice made during by the

expressed

via

T-

Class 2 provides a way to multiplex several transport connections onto a single network connection. This class has been designed to be used with type A network connections. 5.4.6.2 Use of explicit flow control

network services; versus cost ratio The objective is to provide flow control to help avoid congestion at transport-connection-end-points and on the network connection. Typical use is when traffic is heavy and continuous, or when there is intensive multiplexing. Use of flow control can optimize response times and resource utilization. 5.4.6.3 Non-use of explicit flow control

c) the user required service acceptable to the TS-user. 5.4.3

Choice of network connection

The following list classifies network services in terms of aualitv with resoect to error behavior in relation to user requirements; its main purpose is to provide a basis for the decision regarding which class of transport protocol should be used in conjunction with given network connection:

The objective is to provide a basic transport connection with minimal overheads suitable when explicit disconnection of the transport connection is desirable. The option would 6
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typically be used for unsophisticated terminals, and when no multiplexing onto network connections is required. Expedited data is never available. 5.4.; Characteristics of class 3

to be detected include: TPDU loss, TPDU delivery out of sequence, TPDU duplication and TPDU corruption. These errors may affect control TPDUs as well as data TPDUs. NOTE-The transport entity is incapable of distinguishing between failure of the network service and failure of the peer entity, except optionally, by some local means, in the case of the failure of the local interface to the network service (e.g., in the failure of the local
transceiver on a local area network).

Class 3 provides the characteristics of class 2 plus the ability to recover from network disconnect or reset. Selection of this class is usually based upon reliability criteria. Class 3 has been designed to be used with type B network connections. 5.4.6 Characteristics of class 4

Class 4 provides the characteristics of class 3, plus the capability to detect and recover from errors which occur as a result of the low grade of service available from the NSprovider. The kind of errors to be detected include: TPDU loss, TPDU delivery out of sequence, TPDU duplication and TPDU corruption. These errors may affect control TPDUs as well as data TPDUs. This class also provides for increased throughput and additional resilience against network failure. Class 4 has been designed connections. capability

There is no indication given to the transport entity about the ability of the network entity to fulfill the service requirements given in the N-UNITDATA primitive. However, it can be a local matter to make transport entities aware of the availability and characteristics (QOS) of connectionlessmode network services, as the corresponding NSAP exist logically by the nature of the associations, connectionless-mode network service and may be recognized by network entities. 5.6 Model of the transport layer

to be used with type C network

5.5 Characteristics of class when operating over CLNS

4 transport

protocol

A transport entity communicates with its TS-users through one or more TSAPs by means of the service primitives as defined by the transport service definition (see IS0 8072). Service primitives will cause or be the result of transport protocol data unit exchanges between the peer transport entities supporting a transport connection. These protocol exchanges are effected using the services of the Network Layer as defined by the network service definition (see ISO/IEC 6348) through one or more NSAPs. Transport connection endpoints are identified in end systems by an internal, implementation dependent, mechanism so that the TS-user and the transport entity can refer to each transport connection.

In operation over a connectionless-mode network service the class 4 transport procotol provides flow control between communicating peer transport entities, the capability to detect and recover from errors which occur as a result of a low grade of service available from the NS-provider, and resilience from failure of the peer entity. The kinds of error

I
TSAP

NSAP

p

NSAP

NOTE - For the purposes of illustration, figure 2 shows only one TSAP and one NSAP for each transport entity. In certain instances, more than one TSAP and/or more than one NSAP may be associated with a particular transport entity.

Figure 2 - Model of the transport

layer

*
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Section two: Transport protocol specification

6

Elements

of procedure

During the resynchronization a transport connection

after failure (see 6.12) procedures,
This clause contains elements of procedure which are used in the specification of protocol classes in clauses 7 to 12. These elements are not meaningful on their own.

(see 6.14) and reassignment the initiator may reassign to another network connection

joining the same NSAPs, provided that it is the owner of the network connection and that the transport connection is assigned to only one network connection at any given time. During the splitting procedure (see 6.23), a transport entity may assign a transport connection to any additional network connection joining the same NSAPs. provided that it is the owner of the network connection and that either the network connection does not have another transport connection assigned to it; or multiplexing is possible on the network connection.
The transport entity that did not initiate the assignment becomes aware of the assignment when it receives: a) a CR TPDU during procedure (see 6.5); or the connection establishment

The procedures define the transfer of TPDUs whose structure and coding is specified in clause 13. Transport entities shall accept and respond to any TPDU received in a valid NSDU and may issue TPDUs initiating specific elements of procedure specified in this clause.
NOTE -Where network service primitives, TPDUs and parameters used are not significant for a particular element of procedure, they have not been included in the specification. 6.1 Use of the network to service network connection when

6.1.1 Assignment operating over CONS

This procedure is used only when operating connection-mode network service. 6.1.1.1 Purpose

over the

b) an RJ TPDU or a retransmitted CR or DR TPDU during the resynchronization (see 6.14) and reassignment after failure (see 6.12) procedures; or c) any TPDU when splitting (see 6.23) is used. NOTES

The procedure is used in all classes to assign transport connections to network connections.
6.1.4.2 Network service primitives

1 When a new network connection is created, the quality of selvice requested is a local matter, although it will normally be related to the requirements of transport connection(s) expected to be assigned to it.
2

The procedure primitives:

uses

the

following

network

service
An existing network connection may also not be suitable if, for example, the quality of service requested for the transport connection cannot bs attained by using or enhancing the network connection.

a) N-CONNECT; b) N-DISCONNECT.
6.1 .1.3 Procedure

Each transport connection shall be assigned to a network The initiator may assign the transport connection. connection to an existing network connection of which it is the owner or to a new network connection (see note 1) which it creates for this purpose. The initiator shall not assign or reassign the transport connection to an existing network connection 1 the protocol class(es) proposed for the class in use for the transport connectioti are incompatible with the current usage of the network connection with respect to multiplexing (see note 2).

3 A network connection with no transport connection(s) assigned to it, may be available after initial establishment, or because all of the transport connections previously assigned to it have been released. It is recommended that only the owner of such a network connection should release it. Furthermore, it is recommended that it not be released immediately after the transmission of the final TPDU of a transport connection; either a DR TPDU in response to TPDU. An CR TPDU or a DC TPDU in response to DR appropriate delay will allow the TPDU concerned to reach the other transport entity allowing the freeing of any resources associated with the transport connection concerned. 4 After the failure of a network connection, transport connections which were previously multiplexed together may be assigned to different network connections, and vice versa.
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6.1.2 Transmission

over CLNS over the

TPDUs as NS-user data parameters DATA primitives.

of N-EXPEDITED

This procedure is used only when operating connectioniess-mode network service. 6.1.2.1 Purpose

In all other cases, transport entities shall transmit and receive TPDUs as NS-user data parameters of N-DATA primitives. When a TPDU is put into an NS-user data parameter, the significance of the bits within an octet and the order of octets within a TPDU shall be defined in 13.2.
NOTE - TPDUs may be concatenated (see 6.4).

The procedure is used to transmit connectionless-mode network service. 6.1.2.2 Network service primitives

TPDUs over the

6.3 The procedure makes use of the following network service primitive: N-UNITDATA. 6.1.2.3 Procedure 6.3.2 Each TPDU shall be transmitted in a single invocation of the connectionless-mode network service, over a preexisting association between a pair of NSAPs. The association is considered by transport entities as permanently established and available. 6.2 6.2.1 Transport protocol Purpose data unit (TPDU) transfer 6.3.3 6.3.1

Segmenting Purpose

and reassembling

The segmenting and reassembling procedure is used in all classes to map TSDUs onto TPDUs. TPDU and Parameter Used makes use of the following TPDU and

The procedure parameter: DT TPDU -

End of TSDU. Procedure

The TPDU transfer procedure is used in all classes to convey transport protocol data units in user data fields of network service primitives. 6.2.2 Network service primitives

A transport entity shall map a TSDU onto an ordered sequence of one or more DT TPDUs. This sequence shall not be interrupted by other DT TPDUs on the same transport connection. All DT TPDUs except the last DT TPDU in a sequence greater than one shall have a length of data greater than zero.
NOTES

The procedure uses the following network service primitives when operating over CONS:
a) N-DATA;

b) N-EXPEDITED DATA. The procedure uses the following network service primitive when operating over CLNS: N-UNITDATA.
6.2.3 Procedure

1 The EOT parameter of a DT TPDU indicates whether or not there are subsequentDT TPDUs in the sequence. 2 There is no requirement that the DT TPDUs shall be of the
maximum length selected during connection establishment.

6.4
6.4.1

Concatenation
Purpose

and separation

The transport protocol data units (TPDUs) defined for the protocol are listed in 4.2. When operating over CLNS, the transport entities shall transmit and receive all TPDUs as NS-user data parameters of N-UNITDATA primitives. When operating over CONS and when the netv.,ork expedited variant has been selected for class 1, the transport entities shall transmit and receive ED and EA

The procedure for concatenation and separation is used in classes I, 2, 3 and 4 to convey multiple TPDUs in one NSDU. 6.4.2 Procedure

A transpoti entity may concatenate TPDUs from the same or different transport connections, while maintaining the order of TPDUs for a given transport connection pompatible with the protocol operation.
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A valid set of concatenated TPDUs may contain
any number of TPDUs from the following list: AK, EA, RJ, ER, DC TPDUs, provided that these TPDUs come from different transport connections; a)

- CLASS and OPTIONS (i.e. preferred class, use of extended format, non-use of explicit flow control in class 2); calling TSAP-ID; called TSAP-ID; TPDU size (proposed); preferred maximum TPDU size (proposed); version number;

b) no more than one TPDU from the following list: CR, DR, CC, DT, ED TPDUs; if this TPDU is present, it shall be placed last in the set of concatenated TPDUs. A transport entity shall accept a valid set of concatenated TPDUs.
NOTES 1 The TPDUs within a concatenated set may be distinguished by means of the length indicator parameter. 2 The end of a TPDU containing termination of the NSDU. data is indicated by the

protection parameter; checksum; additional option selection (i.e. use of network expedited in class 1, use of receipt confirmation in class 1, non-use of checksum in class 4, use of transport expedited data transfer service, use of selective acknowledgement, use of request acknowledgement); alternative protocol class(es);

3 When operating over CONS the number of concatenated TPDUs referred to in 6.4.2.a) is bounded by the maximum number of transport connections which are multiplexed together except during assignment or reassignment. When operating over CLNS, the number of TPDUs that may be concatenated is bounded by the number of transport connections established between two NSAPs and/or the maximum available NSDU size. 6.5

acknowledgement time; Inactivity time; throughput (proposed); residual error rate (proposed); priority (proposed); transit delay (proposed);

Connection establishment Purpose

reassignment time; user data;

6.5.1

b) CCTPDU The procedure for connection establishment classes to create a new transport connection. 6.5.2
When

is used in all

CDT; DST-REF;

Network service primitives uses the

SRC-REF; CLASS and OPTIONS (selected); calling TSAP-ID; called TSAP-ID; TPDU size (selected); uses the

operating over CONS, the procedure following network service primitive: N-DATA. When operating over CLNS, the procedure following network service primitive: N-UNITDATA. 6.5.3 TPDUs and parameters used

the preferred maximum TPDU size (selected): protection parameter; checksum; additional option selection (selected); acknowledgement Inactivity time; time;

The procedure uses the following TPDUs and parameters:

.

a) CR TPDU CDT; DST-REF (set to zero); SRC-REF;

throughput (selected); residual error rate (selected); priority (selected); transit delay (selected); user data.

1(
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6.5.4

Procedure

for operating

over CONS

the network connection. for transport connections, local matter.

The range of references used in a given transport entity, is a

A transport connection is established by means of one transport entity (the initiator) transmitting a CR TPDU to the other transport entity (the responder), which replies with a CC TPDU. Before sending the CR TPDU, the initiator assigns the transport connection being created to one (or more if the splitting procedure is being used) network connectiori(s). It is this set of network conhections over which the TPDUs are sent. NOTE - Even if the initiator assigns the transport connection to
more than one network connection, all the CR TPDUs (if repeated) or DR TPDUs with DST-REF set to zero which are sent prior to the receipt of the CC TPDU shall be sent on the same network connection, unless an N-DISCONNECT indication is received. (This is necessary because the remote entity may not support class 4 and therefore may not recognize splitting.) If the initiator has made other assignments, it will use them only after receipt of a class 4 CC TPDU (see also the splitting procedure 6.23).

b) calling and called TSAP-IDS (optional): when either network address unambiguously defines the transport address this information may be omitted. c) initial credit: Only relevant for classes the explicit flow control function. which include

d) user data: Not available if class 0 is the preferred class (see the note). Up to 32 octets in other classes.
NOTE - If class 0 is a valid response accordmg to table 3, inclusion of user data in the CR TPDU may cause the responding entity to refuse the connection (for example if it only supports class 0). e) acknowledgement f)

time:

Only in class 4. Only in class 4. This parameter and its

checksum

parameter:

During this exchange, all information and parameters needed for the transport entities to operate shall be exchanged or negotiated.
NOTE - Except in class 4, it is recommended that the initiator starts an optional timer TS7 at the time the CR TPDU is sent. This timer should be stopped when the connection is considered as accepted or refused or unsuccessful. If the timer expires, the initiator should reset or disconnect the network connection, and in classes 1 and 3, freeze the reference (see 6.16). For all other transport connection(s) multiplexed,on the same network connection, the procedures for reset or disconnect as appropriate should be followed.

g) protection parameter: semantics are user defined. h) inactivity

parameter not present

time: Only in class 4. The inactivity time shall not be included in a CC TPDU if it was in the corresponding CR TPDU. take place:

The following

negotiations

.

When an unexpected duplicated CR TPDU is received (with class 4 as preferred class) it shall be ignored in classes 0, 1, 2, and 3 and a CC TPDU shall be returned in class 4. After.receiving the CC TPDU for a class which includes the procedure for retention until acknowledgement of TPDUs the initiator shall acknowledge the CC TPDU as defined in Table 5 (see 6.13). When the network expedited variant of the expedited data (see 6.11) has been agreed (possible in class 1 only), the responder shall not send an ED ,TPDU before the CC TPDU is acknowledged. information is exchanged:

j) protocol class: The initiator shall propose a preferred class and may propose any number of alternative classes which permit a valid response as defined in table 3. The initiator should assume when it sends the CR TPDU that its preferred class will be agreed to, and commence the procedures associated with that class, except that if class 0 or class 1 is an alternative class, multiplexing shall not commence untii a ZC TPDU selecting the use of classes 2, 3 or 4 has been received.
NOTE This means, for example that when the preferred class includes resynchronizatfcn (see 6.14) the resynchronization will occur if a reset is slgpalled durtng connection establishment.

. transfer

The following

The responder shall seleci one class defined in table 3 as a valid response corresponding to the preferred class and to the class(es!. ii ZZ~, r?Kia;ned in the alternatlve class paramerec o! !he CR r'Tp>J. It shall indicate the selected cl ss ? * ihe ZC T?C'J an&shaif follow the procedures ;o: tilt` se!octed class. If tr~s qrafe:red the CC TPDU
according

a) references: Each transport entity chooses a reference to be used by the peer entity which is 16 bits long and which is arbitrary under the following restrictions: 1) it shall 6.1 a), 2) not already be in use nor frozen (see

class 1s noi selected, then on receipt of the initiator shall adjust its ,operation
the selected class.

to the procedures'of

NOTES
1 The valid responses indicated in table 3 result from both explicit negotiation, whereby each of the classes proposed is a valid response, and implicit negotiation whereby

it shall not be zero. and provides independent of

This mechanism is symmetrical identification of the transport connection

a)

If class 3 or 4 is proposed

then class 2 is valid response;
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Table 3 -Valid

responses

corresponding class proposed

to the preferred in the CR TPDU

class and

any alternative Preferred class 0 not valid class.1 or 0 1 not valrd class 1 or 0 not valid class 3,2, 1 or 0 class 4, 2, 1 or 0

Alternative 2 not valid not valid class 2 class 3 or 2. class 4 or 2

class 3 not valid not valid not valid class 3 or 2 class 4, 3 or 2 not not not not class 4 valid valid valid valid 4 or 2 none class 0 class 1 or 0 class 2 class 3 or 2 class 4 or 2

.

t class 2 or 0
class 3, 2 or 0 class 4, 2 or 0

b)

if class 1 is proposed

then class 0 is a valid response.

2 Negotiation from class 2 to class 1 and from any class to an higher-numbered class is not valid. 3 Redundant combinations are not a protocol error.

n) normal or extended format: Either normal or extended is available. When extended is used this applies to CDT, TPDU-NR , ED-TPDU-NR, YR-TU-NR and YR-EDTU-NR parameters. p) checksum selection: TPDUs of the connection q) quality throughput, This defines whether or not are to include a checksum.

k) TPDU size: The initiator may propose a maximum size for TPDUs, and the responder may accept this value or respond with any value between 128 and the proposed value in the set of values available (see 13.3.4 b).
The length octets (see 13.3).

of service parameters: This defines the transit delay, priority and residual error rate.

NOTE -

of the CR TPDU

does

not exceed

128

NOTE - The transport service defines transit delay as requiring a previously stated average TSDU size as a basis for
any specification. This protocol as specified in 13.3.4 p). uses a value at 128 octets. Conversion to and from specifications based upon some other value is a local matter. r)

m) preferred maximum TPDU size: The value of this parameter, multiplied by 128, yields the proposed or accepted maximum TPDU size in octets. The initiator may proposed a preferred maximum size for TPDUs and the responder may accept this value or respond with a smaller value. NOTE - If this parameter is used in a CR TPDU without also
including the TPDU size parameter, this will result in a maximum TPDU size of 128 octets being selected if the remote entity does not recognize the preferred TPDU size parameter. Therefore, it is recommended that both parameters be included in the CR TPDU.

the non-use of explicit flow control

in class 2. and network

s) the use of network receipt confirmation expedited when class 1 is to be used.

t) use of expedited data transfer service: This allows both TS-users to negotiate the use or non-use of the expedited data transport service as defined in the transport service (see IS0 8072).
u) the use of selective acknowledgement: This allows the transport entities to decide whether to use procedures that allow acknowledgement of DT TPDUs that are received out-of-sequence (only in class 4).

If the preferred maximum TPDU present in a CR TPDU the responder

size parameter shall

is

either: ignore the preferred maximum TPDU parameter and follow TPDU size negotiation defined in 6.54 k);

size as

or: use the preferred maximum TPDU size parameter to determine the maximum TPDU size requested by the initiator and ignore the TPDU size parameter. In this case'the responder shall use the preferred maximum TPDU size parameter in the CC TPDU and shall not include the TPDU size parameter in the CC TPDU. If the preferred maximum TPDU size parameter is not present in the CR TPDU it shall not be included in the corresponding CC TPDU. In this case TPDU size negotiation is as defined in 6.5.4 k).

v)' tne use of request acknowledgement: This allows both transport entities to negotiate the use or non-use of the request acknowledgement facility specified in 6.13.4.2 (only in classes.1, 3, 4). The following information is sent only in the CR TPDU:

w) version number: This defines the version of the transport protocol standard used for this connection. x) reassignment time parameter: This indicates time for wfiich the initiator will persist in following reassignment after failure procedure. * the the
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The negotiation rules for initiator may propose either The responder may either select an alternative choice

the options are such that the to use or not to use the option. accept the proposed choice or as defined in table 4.

parameters needed for the transport entities to operate shall be exchanged or negotiated. When an unexpected duplicated CR TPDU is received (with class 4 as preferred class) a CC TPDU shall be returned. After receiving the acknowledge the CC 6.13). The following information CC TPDU, the initiator TPDU as defined in table shall 5 (see

When a parameter [which is valid for the proposed class(es)] is absent and a default value is defined in this International Standard, this is equivalent to the presence of the parameter with the default value. In class 2, whenever a transport entity requests or agrees to the transport expedited data transfer service or to the use of extended formats, it shall also request or agree (respectively) to the use of explicit flow control. Table 4 - Negotiation of options during connection

is exchanged:

a) references: Each transport entity chooses a reference to be used by the peer entity which is Is-bits long and which is arbitrary under the following restrictions: 1) it shall 6.1?). not already be in use nor frozen (see,

establishment

. 2) it shall not be zero.
This mechanism is symmetrical and provides identification of the transport connection itself. The range of references used for transport connections, in a given transport entity, is a local matter. b) called and calling TSAP-IDS (optional): Indicates the calling and called transport service access points. When either the network address unambiguously defines the transport address, this information may be omitted. c) d) e) f) initial credit. user data: up to 32 octets. time.

Non-use of explicit flow control

acknowledgment checksum

.

parameter. This parameter and its

g) protection parameter: semantics are user defined.

h) inactivity time: The inactivity time parameter'shall not be included in a CC TPDU if it was not present in the corresponding CR TPDU. j) protocol class: Class 4 is the only valid value for the preferred protocol class proposed by the initiator, and for the class selected by the responder. An alternative class is not permitted. The following negc iations !akr; place:

I, 3, 4 only)

I

1

I

NOTE - Table 4 defines the procedures for negotiation of options. This negotiation has been designed such that if the `initiator proposes the mandatory implementation option specified in clause 14,the responder has to aqcept use of this option over the transport connection except for the use of the transport expedited data transfer service which may be rejected by the TS-user. If the initiator proposes a non-mandatory implementation option, the responder is entitfed to select use of the mandatory implementation option. for use over the transport connection. 6.5.5 Procedure for operating over CLNS

A transport connection is established by means of one transport entity (the initiator) transmitting a CR TPDU to the other transport entity (the responder), which replies with a CC TPDU. During this exchange, all information and

k) TPDU size: The initiator may propose a maximum size for T?DUs in the set of values available [see 13.3.4 b)]. This value may be limited by the maximum available NSDU size if known, and cannot exceed the maximum NSDU. size for connectionless-mode network service as defined in ISO/IEC 8348. The responder may accept this value or respond with any value between 128 and the proposed value in the set of values available [see 13.3.4 b)]. * NOTES
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1 The length of (see 13.3).

the

CR TPDU does not exceed 128 octets

2 The transport entities may have knowledge. by some local means, of the maximum avai!able NSDU size. m) preferred maximum TPDU size: The value of this parameter, multiplied bji 128, yields the proposed or accepied maximum TPDU size in octets. The initiator may propose a preferred maximum size for TPDUs and the responder may accept this value or respond with a smaller va!ue. NOTE - if this aa;arnater is us& in a GR TPDU without also inc!udiny the T?D;: size parameter, !his will result in a maximum TPIX ~ze of 128 ccie:s being cs!Hed if the remote entip9 does nor reccgniz- thu preferred TPDlJ size parameter. Therefore, it is recommended that both parameters be included in the CR TPDU. If the preferred maximtim TPDU size parameter present in a CR TPDU the responder shall is

t) tne use of request acknowiedgement: This allows both transport entities to negotiate the use or non-use of the request acknowledgement facility specified in 6.13.4.2. The following information is sent only in the CR TPDU:

c) version aumbsr: This defines the version of the transport protocol standard used for this connection. 6.6 6.6.1 Connection Purpose in all classes connection in refusal

The connection refusal procedure is used when a transport entity refuses a transport response to a CR TPDU. 6.6.2 TPDUs and parameters used

either: iyr;are rhe preferred maximum TPDU size paramftec aiid foliaw TPDU size negotiation as de?ined in 5.5.5 k); or: i~se tire preferred maximum TPDU size parameter to determine the maximum TPDU size requested hy tna initiaior and ignore the TPDU size para? ,eter in !his aase the responder shall use the preferred ;n.&mlim -r PDU size parameter in the CC %PDU a+ sba!f no; include the TPDU size parameti-r il' :he CG TPDU. if the preferred maximum TPDU size parameter is not present in ?he CR TPDU it shall not be included in the correspcnding CC TP%U. In this case TPDU size negoiiation is as deftned in 6.5.5 k). n) no:mal or extended extar>*`"d _ .A.. i.5 available format: Either normal or When extended is used this TPD~LhR, ED TPDU-NR, YR-TU-NR parameters. Tinis defines whether or not are to include a checksum.

The procedure

uses the follow TPDUs and parameters:

a) DR TPDU SRC-REF; reason;

__ user data; b) ER`TPDU 6.6.3 reject cause; invalid TPDU. Procedure

appi& to CC)7 ..
and YF-EDTGNR

If a transport connection cannot be accepted, the responder shall respond to the CR TPDU with a DR TPDU. The reason shall indicate why the connection was not accepted. The source reference field in the DR TPDU shall be set to zero to indicate an unassigned reference. If a DR TPDU is received connection as released. the initiator shall regard the

p) checksum seiec?ion: TFDUs of the connection q) quality throughput.

of service parameters: This defines the transit delay, priority and residual error rate.

NCTE -The transport service defines transit delay as requiring a previously stated average TSDU size as a basis for any specification. This protocol as specified in 13.3.4 p), uses a value at 128 octets. Conversion to and from specifications based upon some other value is a local matter. r) use of expedited data transfer service: This allows both TS-users to negotiate the use or non-use of the expedited data transport service as defined in the transport service (IS0 8072). s) the use of selective acknowledgement: This allows the transport entities to decide whether to use procedures that allow acknowledgement of DT TPDUs that are received out-of-sequence.

The responder shall respond to an invalid CR TPDU by sending an ER or DR TPDU. If an ER TPDU is received in response to a CR TPDU, the initiator shall regard the connection as released. NOTES 1 When the invalid CR TPDU can be identified as having class 0 as the preferred class, it is recommended to respond with an ER TPDU. For all other invalid CR TPDUs either an ER TPDU or DR TPDU may be sent.
If the optional supervisory timer TSI has been set for this connection then the initiator should stop the timer on receipt of the * DR or ER TPDU. 2

3 It is a local matter whether the initiator releases the network connection if no transport connectlons are now assigned to it. 20
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6.7 6.7.1 6.7.1 .l

Normal

release release when operating over CONS

2) discard all subsequently than a DR or DC TPDU;

received

TPDUs released

other on

Normal

3) consider the transport connection receipt of a @R or DC TPDU; b) If a) is not applicable CR TPDU, it shall and if there

Purpose

is an outstanding

The release procedure is used by a transport entity in order to terminate a transport connection. The implicit variant is used only in class 0. The explicit variant is used in classes 1, 2, 3 and 4. NOTES
1 When the implicit variant is used (i.e. in class 0), the lifetime of the transport connection is directly correlated with the lifetime of the network connection.

1) for classes other than class 4 wait for the acknowledgement of the outstanding CR TPDU; if it receives a CC TPDU, is shall follow the procedures in 6.7.1.5.a). 2) for class 4 either send a DR TPDU with a zero value in the DST-REF field or follow the procedure in 6.7.1.5.b)l. In the former case further receipt of a CC TPDU specifying class 4 will be ignored. Receipt of CC TPDU with another class will be processed as follows: If the class is 0 the network connection shall be disconnected, otherwise a DR TPDU with the DST-REF fie!d set to the value of the SRC-REF field of the received CC TPDU shall be sent and the release procedure of the class is continued. A transport entity that receives a DR TPDU shall

2 The use of the explicit variant of the release procedure enables :he transport connection to be released independently of the underlying network connection. 6.7.1.2 Network service primitives the following network service

The procedure primitives:

uses

a) N-DISCONNECT, b) N-DATA. 6.7.1.3 TPDUs and parameters uses the following used

c) If it has previously sent a DR TPDU for the same transport connection, consider the transport connection released;
d) If it has previously sent a CR TPDU that has not been acknowledged by a CC TPDU, consider the connection refused (see 6.6). if the SRC-REF is not zero a DC TPDU using the SRC-REF as the DST-REF; shall be sent

The procedure a) DRTPDU -

TPDUs and parameters

NOTE - In this case the DR has been associated regardless of its SRC-REF field (see 6.9.1.4 and 6.9.2.4). e) if c) and d) are not applicable, send a DC TPDU and consider the transoort connection released. If the received DR has the DST-REF field set to zero, then a DC with SRC-REF set to zero shall be sent, regardless of the local reference. NOTE - If the entity receiving such a DR TPDU has previously decided to negotiate down the class, thus entity is always entitled ) consider such a DR TPDU as spurious. Since no association has been made the transport connection is not released at the responder side but the CC TPDU, when sent, will be answered by a DR TPDU (spurious CC TPDU). NOTES 1 This requirement ensures that the transport entity is aware of the remote reference for the transport connection, 2 When the transport connection is considered as released the local reference is either available for re-use or is frozen (see 6.16).
3 After the release of a transport connection the network connection can be released or retained to enable its re-use for the assignment of other transport connections (see 6.1.1).

reason; user data; SRC-REF; DST-REF;

b) DCTPDU. 6.7.1.4 Procedure for implicit variant

In the implicit variant either transport entity disconnects a transport connection by disconnecting the network connection to which it is assigned. When a transport entity receives an N-DISCONNECT this should be considered as the release of the transport connection. 6.7.1.5 Procedure for explicit variant connection is to be initiated,

When the release of a transport a transport entity a) if it has previously note 1) shall

sent or received

a CC TPDU (see

1) send a DR TPDU;
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4 Except in class 4, it is recommended that, if a transport entity does not ret&e acknowledgement of a DR TPDU within time TS2, it should either reset or disconnect the network connection, and freeze the reference when appropriate (see 6.16). For all other transport connection(s) multiplexed on this network connection the procedures for reset or disconnect as appropriate should be followed. 5 When a transport entity is waiting for a CC TPDU before sending a DR TPDU and the network connection is reset or released, it should consider the transport connection released and, in classes other than classes 0 and 2, freeze the reference (see

expiration of the CR TPDU retransmission DR TPDU to be sent.

counter,

which forces the

A transport

entity which receives

a DR TPDU shall if it

a) consider the transport connection to be released has previously sent a DR TPDU for that connection; b) consider the transport 6.6) if it has previously connection and no CC acknowledgment;

connection to be refused (see sent a CR TPDU for that TPDU has been received in

6.18). 6.7.2 6.7.2.1 Normal release when operating over CLNS c) consider the transport connection to be released and send a DC TPDU in all other cases. If the received DR TPDU has the DST-REF field set to zero, then a DC TPDU with SRC-REF set to zero shall be sent, regard less of the local reference. 6.8 6.8.1 6.7.2.2 Network service primitives makes use of the following network service This procedure is used only in classes 0 and 2 io release a transport connection on the receipt of an N-DISCONNECT or N-RESET indication. 6.8.2 used and parameters: Network service primitives service primitives: Error release when operatin,g over CONS Purpose

Purpose entity in order

The release procedure is used by a transport to terminate a transport connection.

The procedures primitive: N-UNITDATA. 6.7.2.3

TPDUs and parameters uses the following

The procedure

uses the following request; indication;

The procedure

TPDUs

a) N-DISCONNECT b) N-DISCONNECT c) N-RESET

a) DR TPDU; reason; user data; SRC-REF; DST-REF;

jndication; response.

d) N-RESET 6.8.3

Procedure

b) DCTPDU. 6.7.2.4 Procedure

'

When the release of a transport connection is to be initiated, a transport entity shall send a DR TPDU and shall discard all subsequently received TPDUs except for a DR or a DC TPDU. On the receipt of a DR or a DC TPDU, it shall consider the transport connection to be released and the local reference shall be frozen (see 6.16). If a CC TPDU has been previously sent or received by the transport connection, then the remote reference is known and shall be used for the DST-REF in the DR TPDU to be sent. If the remote reference is not known, then the DST-REF in the DR TPDU may be set to zero, or the entity may wait until a CC TPDU is received before sending the DR TPDU.
NOTE - In case that the envy dacrdes to wait for the arrival of the CC TPDU for the connection, deadlock could result from a CC TPDU that never arrives. Such a deadlock is prevented by the

When, on the network connection to which a transport connection is assigned, an N-DISCONNECT or N-RESET indication is received, both transport entities shall consider that the transport connection is released and so inform the TS-users. On receipt of an N-RESET in class issued; indication: request shall be

0, an N-DISCONNECT

in class 2, it is a local choice to issue an N-RESET response or an N-DISCONNECT request; one of these primitives shall be issued. However, if the Network Connection has other Transport Connections of a diiferent class assigned to it, the error recovery procedure of that class shall be used to determine which primitive is issued.

t
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6.9

Association

of TPDUs with transport TPDUs with over CONS

connections transport

assigned to this network connection (if any), apply the procedures defined for handling of network signalled reset or disconnect. If the NSDU can be decoded transport entity shall and is not corrupted, the

Association of 6.9.1 connections when operating 6.9.1.1 Purpose

This procedure is used in all classes to interpret NSDU as TPDU(s) and, if possible, to associate TPDU with a transport connection. 6.9.1.2 Network service primitives uses the following

a received each such

a) if the network connection on which the NSDU was received has a class 0 transport connection assigned to it, consider the NSDU as forming one TPDU and associate the.TPDU with the transport connection (see 6.9.1.4.2); b) otherwise, invoke the separation procedures and for each of the individual TPDUs in the order in which they appear in the NSDU apply the procedure defined in 6.9.1.4.2. 6.9.1.4.2 Association of individual TPDU

.
network service

The procedure primitives:

a) N-DATA indication; b) N-EXPEDITED c) N-RESET DATA indication;

request; request. used

d) N-DISCO.NNECT 6.9.1.3

If the received TPDU is a CR TPDU. then if the SW-REF parameter and the remote NSAP indicate an existing transport connection at that receiving entity, then the CR TPDU is associated with that transport connection, otherwise it is processed as requesting the creation of a new transport connection. If the received TPDU is a DT TPDU and the network connection has no TC assigned to it, and the DT TPDU is a class 0 or class 1 TPDU (as recognized by the absence of a DST-REF field), then the TPDU should be ignored. 0 Otherwise, the DST-REF parameter .of the TPDU is used to identify the transport connection. The following cases are distinguished: a) If the DST-REF is not allocated to a transport connection then no association with a transport connec!ion is made and there are three cases:

TPDUs and parameters uses the following

The procedure

TPDUs and parameters:

a) any TPDU except CR TPDU, DT TPDU in classes or 1 and AK TPDU in class 1 DST-REF;

b) CR, CC, DR and DC TPDUs SRC-REF;

c) DT TPDU in classes 0 or 1 and AK TPDU in class 1. 6.9.i.4 6.9.1.4.1 Procedures Identification of TPDUs

1) If the TPDU shall respond on DR TPDU. The either 0 or the TPDU;

is a CC TPDU the transport entity the same network connection with a SRC-REF of the DR. TPDU may be DST-REF from the received CC

.

If the received NSDU or expedited NSDU cannot be decoded (i.e. does not contain one or more correct TPDUs) or is corrupted (i.e. contains a TPDU with a wrong checksum) then the transport entity shall a) if the network connection on Which the error is detected has a class 0 or 1 transport connection assigned to it, treat as a protocol error (see 6.22) for that transport connection: b) otherwise: 1) if the NSDU can be decoded but contains corrupted TPDUs, discard the TPDUs (class 4 only) and optionally apply 6.9.1.4.1 b)2); 2) if the NSDU cannot be decoded issue an NRESET or N-DISCONNECT request for the network connection and for all the transport connections

2) If the TPDU is a DR TPDU the transport entitv shall respond on the same netyvork connection with a DC TPDU; except in the case that the DR is carrying aSRC-REF set to zero, then no DC TPDU shall be sent, or in the case where the transport entity only supports class 0 then the network connection shall be disconnected; 3) If the TPDU discarded; is neither a CC or DR it shall be

b) If the DST-REF is a!located to a transport connection, but the TPDU is received on a network connection to which this connection has not been assigned then there are four cases: 1) if the transport connection is of class 4 and if the TPDU is received on a network connection with the same pair of NSAPs as that of the CR TPDU then the TPDU is associated with this t\ansport
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connection assignment;

and

considered

as

performing

2) if the transport connection is not assigned to any network connection (waiting for reassignment after failure) and if the TPDU is received on a network connection with the same pair of NSAPs as that of the CR TPDU then the association with that transport connection is made, except in the case of DC, DR and CC TPDUs which are respectively described in 6.9.1.4.2 c), d), e); 3) In classes l and 3, it is also possible to receive a TPDU performing reassignment prior to the notification of the disconnect of the current network connection (i.e. the transport connection is assigned to a network connection, but a TPDU containing the appropriate DST-FIEF is received on another network connection). In this case it is recommended that the transport entity: issue an N-DISCONNECT request on the network connection to which the transport connection is cuirently assigned, apply to all transport connections assigned to this network connection the procedure for processing a received N-DISCONNECT indication, and then reassignment; process the TPDU performing as having a connection

reference, then a DR TPDU is sent back with DST-REF equal to the SRC-REF of the received CC TPDU and no association is made. 1) if none of the above cases apply then the TPDU is associated with the transport connection identified by the DST-REF parameter. Association of 6.9.2 connections when operating 6.9.2.1 purpose TPDUs with over CLNS transport

This procedure is used to interpret a re-sived NSDU as TPDU(s) and, if possible, to associate each such TPDU with a transport connection. 6.9.2.2 Network service primitives makes use of the following network service

This procedure primitive:

N-UN1 TDATA. 6.9.2.3 TPDUs and parameters makes used TPDUs and

4) otherwise, the TPDU is considered DST-FIEF not allocated to a transport [case a)];

This procedure parameters:

use of the following

a) all TPDUs except CR TPDU: - DST-REF; b) CR, CC, DR and DC TPDUs; - SRC-REF.

c) If the TPDU is a DC TPDU then it is associated with the transoort connection to which the DST-REF is allocated,`unless the SRC-REF is not the expected one, in which case the DC TPDU is discarded. d) if the TPDU is a DR TPDU then there are four cases: 1) if the SRC-REF is not as expected the; a DC TPDU with DST-REF equal to the SRC-REF of the received DR TPDU is sent back and no association is made, except that in the case where the transport entity only supports class 0 and cannot trarismit a DC TPDU, it disconnects the network connection instead of transmitting a DC TPDU; 2) if a CR TPDU is unacknowledged then the DR TPDU is associated with the transport connection, regardless of the value of its SRC-REF parameter; 3) if the transport entity implements class 4 and if the DST-REF is zero and there is an unacknowledged CC TPDU or T-CONNECT RESPONSE is awaited, then the DR TPDU shall be associated with the transport connection holding the SRC-REF as the remote reference; 4) otherwise, the DR TPDU is associated with the transport connection identified by the DST-REF parameter; e) if the TPDU is a CC TPDU whose DST-REF parameter identifies an open connection (one for which a CC TPDU has been previously received), and the SRC-REF in the CC TPDU does not match the remote

6.9.2.4 6.9.2.4.1

Procedures Identification of TPDUs

If the received NSDU cannot be decoded (i.e., does not contain one or more correct TPDUs) or is corrupted (i.e., contains a TPDU with a wrong checksum) then the transport entity shall ignore (discard) the TPDUS. If the NSDU can be decoded and is not corrupted, the transpor! entity shall invoke the separation procedures and for each of the individual TPDUs in the order in which they appear in the NSDU apply the procedure in 6.9.2.4.2. 6.9.2.4.2 Association of individual TPDUs

Association of a received TPDU with a transport connection is generally performed by attempting to match the DST-REF in the received TPDU and the NSAP pair over which it was received with those of an existing transport connection. There are three exceptions to this general procedure: when the received TPDU is a CR TPDU, the SRC-REF is used instead of the DST-REF; when the received TPDU is either a DR or a DC TPDU, the SRC-REF is used in addition to the DST-REF; and when the received TPBU is a CC TPDU, whose DST-REF parameter identifies an open connection
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(one for which a CC TPDU has been previously received), then the SRC-REF is used in addition to the DST-REF. The following actions shall be taken in consequence to the inability to match the TPDU to an existing transport connection: a) for a CR TPDU. created. a new transport connection shall be

allocate one.

a sequence

number

one greater than the previous

When a DT TPDU is retransmitted, the TPDU-NR parameter shall have the same value as in the first transmission of that DT TPDU Modulo 27 arithmetic shall be used when normal formats have been selected and modulo 9' arithme?ic shall be used In this when extended formats have been selected. international Standard the relationships "greater than" and "less than" apply to a set of contiguous TPDU numbers whose range is less than the modulus and whose starting and finishing numbers are known. The term "less than" means "occurring sooner in the window sequence" and the term "greater than" means "occurring later in the window sequence". 6.11 6.11.1 CONS TPDU 6.11.1.1 Expedited data transfer data transfer when operating over

b) for a CC TPDU, a DR TPDU shall be sent using the the received CC TPDU SRC-REF and DST-REF from as the DST-REF and SRC-REF, respectively, of the DR TPDU.

4

for a DR TPDU, there are four cases: 1) if a CR TPDU is unacknowledged for connection identified by the DST-REF in the TPDU, then the DR TPDU is associated with connection reaardless of the SRC-REF in the TPDU. the DR that DR

Expedited

2) if the CR TPDU for the connection identified by the DST-REF of thehas DFbeen acknowledged and the SRC-REF is not as expected, then a,DC TPDU using the SRC-REF of the DR TPDU as DST-REF is sent and no association is made. 3) if the DST-REF in the DR TPDU is zero and there is an unacknowledged CC TPDU or a TCONNECT response is awaited for a transport connection holding remote reference equal to the SRC-REF of the DR TPDU, then the DR TPDU is associated with that transport connection. TPDU 4) in all other situations, the DR associated with the transport connection identified the DST-REF of the DR TPDU. is by

Purpose

Expedited data transfer procedures are selected during connection establishment. The network normal data variant The network may be used in classes 1, 2, 3 and 4. expedited variant is only used in class 1. 6.11.1.2 Network service primitives the following network service

The procedure primitives: a) b) 6.11.1.3 N-DATA;

uses

d)
6.10 6.10.1

For all other

TPDU types, the TPDU is discarded.

N-EXPEDITED

DATA. used

Data TPDU numbering Purpose

TPDUs and parameters uses the following

The procedure a) EDTPDU b)

TPDUs and parameters:

Data TPDU numbering is used in classes 1,2 (except when the non-use of explicit flow control option is selected), 3 and 4. Its purpose is to enable the use of recovery, flow control and resequencing functions. 6.10.2 TPDUs and parameters used TPDU and parameter:

ED TPDU-NR;

EATPDU YR-EDTU-NR. Procedures

The procedure DT TPDU -. 6.10.3

uses the following

6.11.1.4

TPDU-NR. Procedure

The TS-user data parameter of each T-EXPEDITED DATA request shall be conveyed as the data field of an Expedited Data (ED) TPDU. Each ED TPDU rs_eived shall be acknowledged Expedited Acknowledge (EA) TPDU. by an

A transport entity shall allocate the sequence number zero to the TPDU-NR of the first DT TPDU which it transmits for a transport connection. For subsequent DT TPDUs sent on the same transport connection, the transport entity shall

No more than one ED TPDU shall remain unacknowledged at any time for each direction of a transport connection.
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An ED TPDU with a zero length data field shali be treated as a protocol error.
NOTES 1 The network normal data variant is used, except when the network expedited variant (available in class 1 only), has been agreed. in which case ED and EA TPDUs are conveyed in the data fields of N-EXPEDITED DATA primitives (see 6.2.3). 2 No TPDU can be transmitted using the network expedited variant until the CC TPDU becomes acknowledged, to prevent the network expedited variant from overtaking the CC TPDU.

6.12 Reassignment CONS 6.12.1 Purpose

after iailure

w'hen operating

over

The reassignment after failure procedure is used in classes 1 and 3 to commence recovery from an NS-provider signalled disconnect. 6.12.2 Network service primitives

The procedure uses the following network service primitive: N-DISCONNECT indication 6.j2.3 Procedure

6.11.2

Expedited

data transfer

when operating

over

CLNS 6.11.2.1

Purpose are selected during

Expedited data transfer procedures connection establishment. 6.11.2.2 Network service primitives

When an N-DISCONNECT indication is received for the network connection to which a transport connecti0.n is assigned, the initiator shall apply one of the following alternatives: a) if the TTR timer has not already run out and no DR TPDU is retained 1) assign the transport connection to a different network connection (see 6.1.1) and start its TTR timer if not already started
2) while waiting for the completion of assignment if

The procedure makes use of the following network service primitive: N-UNITDATA. 6.11.2.3 TPDUs and parameters used makes use of the following TPDUs and

The procedure parameters:

- an N-DISCONNECT indication. repeat the procedure from 6.12.3.a); - the TTR timer 6.12.3 b); expires, begin

is received, procedure

a) ED TPDU; ED TPDU-NR;

b) EATPDU; 6.11.2.4 YR-EDTU-NR. Procedures

3) when reassignment is complete perform active resynchronization by executing the procedure described in 6.14.4.1, and, if 6.14.4.1 b) has been performed, wait for the next event as follows: - if a valid TPDU is received as the result of the resynchronization, stop the TTR timer, or -' if TTR runs out, wait for the next event, or

The TS-user data parameter of each T-EXPEDITED DATA request shall be conveyed as the data field of an Expedited Data (ED) TPDU. Each ED TPDU received shall be acknowledged Expedited Acknowledge (EA) TPDU. by an

- if an N-DISCONNECT indication is received, begin either procedure 6.12,3 a) or 6.12.3 b) depending on the TTR timer. NOTE - After TTR expires and while waiting for the next event, it is recommended that the initiator set a timer with a value equal to TWR. If this timer expires before the next event, the initiator should begin the procedure in 6.12.3 b). b) If the TTR timer has run out, consider the transport connection as released and freeze the reference (see 6.18); c) if a DR TPDU is retained and the TTR timer has not run out, then follow the actions in either 6.12.3.a) or 6.12.3.b). c

Nomore than one ED TPDU shall remain unacknowledged at any time for each direction of a transport connection. An ED TPDU with a zero length data field shall be treated as a protocol error (see 6.22).
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The responder shall start its TWR timer if not already started. `The arrival of the first TPDU related to the transport connection (because of resynchronization by the initiator) completes the reassignment after failure procedure. The TWR timer is stopped and the responder shall continue with resynchronization (see 6.14). If reassignment does not take place within this time, the transport connection is considered released and the reference is frozen (see 6.18). 6.12.4 Timers after failure procedure uses two timers:

The confirmation of receipt variant is used only in class 1 when it has been agreed during connection establishment (see the note). The AK variant is used in classes 3 and 4 and also in class 1 when the confirmation of receipt variant has not been agreed during connection establishment. In addition, in Class 4, the option of using selective acknowledgement may be agreed to during connection establishment. The request acknowledgement procedure is selected during connection establishment and may be used in classes 3 and 4, and in class 1 when the confirmation of receipt variant has not been agreed during connection establishment. It allows a transport entity,to request acknowledgement of retained DT TPDUs by setting the ROA parameter in a transmitted DT TPDU. NOTE - Use of the confirmation of receipt variant depends on the availability of the network layer receipt confirmation service and the expected cost reduction. 6.13.2 Network service primitives procedure uses the

The reassignment

a) TTR, the time to try reassignment/resynchronization timer; b) TWR, the resynchronization time to timer. wait for reassignment/

The TTR timer is used by the initiator. Its value shall not exceed 2 min minus the sum of the maximum disconnect propagation delay and the maximum transit delay of the network connections (see note 1). The value for the TTR timer may be indicated in the CR TPDU. If the The TWR timer is used by the responder. reassignrnent time parameter is present in the CR TPDU, the TWR timer value shall be greater than the sum of the TTR timer plus the maximum disconnect propagation delay plus the maximum transit delay of the network connections. If the reassignment time parameter is not present in the CR TPDU, a default value of 2 min shall be used for the TWR timer. NOTES 1 Provided that the required quality of service is met, lTR may be set to zero (i.e. no reassignment). This may be done, for example, rf the rate of NS-provider generated disconnects is very low. 2 Inclusion of the reassignment time parameter in the CR TPDU

When operating following network a) N-DATA; b) N-DATA

over CONS, the service primitives:

ACKNOWLEDGE. over CLNS, the service primitive: procedure uses the

When operating following network N-UNITDATA. 6.13.3

TPDUs and parameters uses the following

used TPDUs and parameters:

The procedure

a) CR, CC, DR and DC TPDUs; b) AKTPDU YR-TU-NR selective acknowledgement parameters;

' allows the responder to use a TWR value of less than 2 min.
3 If the optional TSl and TS2 timers are used, it is recommended a) to stop TSl or TS2 if running when TTR or TWR is started; b) to restart TSl or TS2 if necessary when the corresponding TPDU (CR TPDU or DR TPDU respectively) is repeated; c) to select for TSI and TS2 values greater than TTR. d) 6.13 6.13.1 Retention Purpose and acknowledgement of TPDUs DTTPDU e) TPDU-NR; c)

RJ TPDU YR-TU-NR:

ED TPDU ED-TPDU-NR:

The retention and acknowledgement of TPDUs procedure is used in classes 1, 3 and 4 to enable and minimize retransmission after possible loss of TPDUs.

1)

EATPDU YR-EDTU-NR.
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6.13.4 6.13.4.1

Procedures Retention until acknowledgement of TPDUs

on receipt of an AK TPDU acknowledgement parameter(s) TPDUs specified.
b)

containing selective shall discard the DT

NOTES (Notes 1 to 3 only apply when operating Copies of the following TPDUs shall be retained transmission to permit their later retransmission: CR, CC, DR, DT and ED TPDUs except in the following case: if a DR TPDU is sent in response to a CR TPDU there is no need to retain a copy of the DR TPDU. A copy of each of these TPDUs shall be retained a) it is acknowledged, as specified until upon

over CONS)

1 It is a local matter for each transport entity to decide which N.DATA requests should have the confirmation request parameter set. This decision will normally be related to the amount of storage available for retained copies of the DT TPDUs.
2 Use of the confirmation quality of network sefvice. 3 request parameter may affect the

In class 3, and in class 1, when use of explicit AK variant is selected, if a transport eritity does not send an AK TPDU after reception of each DT TPDU. it is recommended that it starts a trmer after reception of DT TPDU;

in table 5; or

b) the transport 6.13.4.2

connection

is released.

Confirmation

of receipt variant variant, applicable only in

sends an AK TPDU with up-to-date window information at expiration of the timer if an AK TPDU with the same window information has not been previously sent. SelectIon of the value of this timer is a local matter performance. but may affect

In the confirmation of receipt Class 1, transport entities shall a) set the confirmation data parameter contains and 2);

request parameter only if the a CC or DT TPDU (see notes 1

4 It is recommended that, if the sendfng transport entity has a restrictlon in the number of DT TPDUs that it can retain, then it set the ROA parameter to avoid a delay in transmitting DT TPDUs due to the remote transport entity operating an AK withholding policy.

b) issue an N-DATA ACKNOWLEDGE request when it receives an N-DATA indication with the confirmation request parameter set. 6.13.4.3 Request of acknowledgement option has been Retained TPDU CR DR

Table 5 - Acknowledgement Variant

of TPDUs -

Retained until acknowledged by: CC, DR or ER TPDU DC or DR (in case of collision; TPDU N-DATA ACKNOWLEDGE indication, RJ, DT, EA or ED TPDU RJ, DT, AK, ED or EA TPDU N-DATA ACKNOWLEDGE indication corresponding to an N-DATA request which conveyed, or came after, the DT TPDU AK or RJ TPDU for which the YR-TU-NR is greater than TPDU-NR in the DT TPDU. Ir case of selective acknowledgement, if the selective acknowledgement parameters in the AK TPDU include the TPDU-NR of the DT TPDU. EA TPDU for which the YREDTU-NR is equal to the EDTPDU-NR in the ED TPDU

If the request acknowledgement negotiated, transport entities

procedure

Both Both

a) may request acknowledgement of retained DT TPDUs by setting the ROA parameter in a transmitted DT TPDU. The decision as to when the sending transport entity should request acknowledgement is a local matter (see note 4). b) On receipt of a DT TPDU with the ROA parameter set shall transmit an AK TPDU containing up-to-date window information. 6.13.4.4 Selective acknowledgement option

cc

Confirmation of receipt variant AK variant Confirmation of receipt variant

cc DT

DT If the selective acknowledgement negotiated, transport entities option has been

AK variant

a) may include selective acknowledgement parameters in a transmitted AK TPDU. These selective acknowledgement parameters, i! included, shall contain acknowledgement of blocks of TPDUs not acknowledged by the YR-TU-NR field of the AK TPDU. This procedure allows transport entities to acknowledge DT TPDUs that are within the window but that are not in sequence.

ED

Both
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6.14 6.14.1

Resynchronization Purpose

a) if the TTR timer has been previously started and has run out (i.e. no valid TPDU has been received,), the procedures defined in 6.12.3 a)3) shall apply; b) otherwise, the TTR timer shall be started (unless it is already running) and the first which become applicable of the following actions shal! be taken: 1) if a CR TPDU is unacknowledged, transport entity shall retransmit it; then then the the

The resynchronization procedures are used in classes 1 and 3 to restore the transport connection to normal after a reset or during reassignment after failure according to 6.12. 6.14.2 Network service primatives network service primitive:

The procedlure uses the following N-RESET 6.14.3 indication.

2) if a DR TPDU is unacknowledged, transport entity shall retransmit it;

3) otherwise, the transport entity shall carry out the data resynchronization procedures (6.14.4.3). used TPDUs and parameters: 6.14.4.2 Passive resynchronization procedures

TPDUs and parameters uses the following

The procedure

a) CR, DR, CC, and DC TPDUs; b) RJ TPDU c) YR-TU-NR;

The transport entity shall not send any TPDUs until a TPDU has been received. The transport entity shall start its TWR timer if it has not already been started (due to a previous NDISCONNECT or N-RESET indication). If the timer runs out prior to the receipt of a valid TPDU which commences resynchronization (i.e. CR or DR or ED or RJ TPDU) the transport connection is considered as released and the reference is frozen (see 6.16). When a valid TPDU is received the transport entity shall stop its TWR timer and carry out one of the following appropriate actions, depending on the TPDU: a) if it is a DR TPDU, send a DC TPDU; then the transport entity shall

DTTPDU TPDU-NR;

d) ED TPDU e) ED-TPDU-NR;

EATPDU YR-EDTU-NT. procedure of the occurrence of a N2) if the responder wants to release the transport connection or refuse the CR TPDU: (re)transmit the DR TPDU, setting the source reference to zero; 3) if the T-CONNECT received from the user: response has not yet been take no action; b) if it is a repeated CR TPDU (see note 1) the transport entity shall carry out the appropriate action from the following: 1) if a CC TPDU has already acknowledged: treat as a protocol been error; sent, and

6.14.4

A transport entity which is notified RESET shall:

a) if the transport enti?y is the responder, carry out the passive resynchronization procedure (see 6.14.4.2); b) if the transport nothing; entity has elected not to reassign, do

c) otherwise, execute the active resynchronization procedure described in 6.14.4.1 and, if 6.14.4.1 b) has been performed, wait for the next event as follows: if a valid TPDU is received resynchronization, stop the lTR as the result of the timer, or

4) otherwise: (re)transmit the CC TPDU, followed by retransmission of any unacknowledged ED TPDU note 2) and retransmission of the (see unacknowledged UT TPDUs, subject to any applicable flow control procedures. NOTES 1 A repeated CR TPDU can be identified by being on a network connection with the appropriate network addresses and having a correct source reference. 2 The transport entity should not use network expedited until the CC TPDU is acknowledged (see 6.5). This rule prevents the network expedited from overtaking the CC TPDU. tl

if TTR runs out, wait for the next event, or indication is received, perform

if an N-RESET 6.14.4. 6.14.4.1

Active resynchronization entity shall carry

procedures out one of the following

The transport actions:
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c) if it is an RJ or ED TPDU then one of the following actions shall be taken: 1) if a DR TPDU is unacknowledged, transport entity shall retransmit it; then the

6.15.3

Procedure

The transport entities shall be able to send and receive on the same network connection TPDUs belonging to different transport connections. NOTES
1 When performing demultiplexing the transport connection to which the TPDUs apply is determined by the procedures defined in 6.9.

2) if a CC TPDU is unacknowledged, the RJ or ED TPDLJ shall be considered as acknowledging the CC TPDU, and the transport entity.shall carry.out the data resynchronization procedures (6.14.4.3); 3) otherwise, the transport entity shall carry out the data resynchronization procedures (6.14.4.3). 6.14.4.3 Data resynchronization procedures out the following actions in

2 Multiplexing allows the concatenation of TPDUs belonging to different transport connections to be transferred In the same NDATA primitive (see 6.4). 6.16 6.16.1 Explicit flow control Purpose

The transport entity shall carry the following order: a) (re)transmit

any ED TPDU which is unacknowledged.

b) transmit an RJ TPDU with YR-TU-NR field set to the TPDU-NR of the next expected DT TPDU; c) wait for the next TPDU from the other transport entitv. unless an RJ or DR TPDU has alreadv been receiied; if a DR TPDU is received the transpoh entity shall send a DC TPDU, freeze the reference, inform the TS-user of the disconnection and take no further action [i.e. it shall not follow the procedures in 6.14.4:3 d)]. If an RJ TPDU is received, the procedure of 6.14.4.3 d) shall be followed. If an ED TPDU is received the procedures as described in 6.11 shall be followed. If it is a duplicated ED-TPDU the transport entity shall acknowledoe it with an EA.TPDU. discard the duolicated ED TPDU and wait again for the next TPDU; ' d) (re)transmit any QT TPDUs which are unacknowledged, subject to any applicable flow control procedu'res (see the note). NOTE -The RJ TPDU may have reduced the credit. and demultiplexing when operating

The explicit flow control procedure is used in classes 2, 3, and 4 to regulate the flow of DT TPDUs independently of the flow control in the other layers. 6.16.2 TPDUs and parameters uses the following used TPDUs and parameters:

The procedure

a) CR, CC, AK and RJ TPDUs ' b) CDT:

DTTPDU TPDU-NR; ROA;

c)

AKTPDU

-

YR-TU-NR; subsequence number;

6.15 Multiplexing over CONS 6.15.1 Purpose

d)

flow control confirmation; selective acknowledgement parameters;

RJ TPDU 7 YR-TU-NR. Procedure differ in differen! classes. They are defined

The multiplexing and demultiplexing procedures are used in classes 2. 3 and 4 to allow several transport connections to share a network connection at the same time. 6.16.3 6.15.2 TPDUs and parameters used

'

The procedures The procedure uses the following TPDUs and parameters:

' in the clauses specifying the separate classes.
6.17 6.17.1 Checksum Purpose is used to detect * corruption of

CC, DR. DC, DT, AK, ED, EA, RJ, and ER TPDUs DST-REF

The checksum' procedure TPDUs by the NS-provider.
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NOTE - Although a checksum algorithm has to be adapted to the type of eirors expected on the network connection, at present, only one algorithm is defined. 6.17.2 TPDUs and parameters uses the following used TPDUs and parameters:

2 If the checksum is incorrect, it is impossible to know with certainty to which transport connection the TPDU is related; further action may be required dependent on the type of network service in use (see 6.9.1 for CONS and 6.9.2 for CLNS). 3 The checksum proposed is easy to calculate and so will not impose a heavy burden on implementations. However, it will not detect insertion or loss of leading or trailing zeros and will not detect some octets misordering. 4 When CONS is used and a TPDU is received on a network connection, it is impossible io know with certainty that only class d transport connections use this network connection as it may be a TPDU p'erforming reassignment. Consequently, the only way to check the validity is as follows: a) if the network connection is used by a class 0 or class transport connection, there is no checksum; examine the TPDU code; deduce the fixed part length; from LI, deduce the valuable part;

The procedure All TPDUs -

checksum. Procedure

6.17.3

The checksum shall be used only in class 4. It shall always be used for the CR TPDU, and shall be used for all other TPDUs unless the non-use of the checksum was selected during connection establishment. The sending transport entity shall transmit TPDUs with the checksum parameter set such that the following formulae are satisfied:

1

$7

= 0 (modulo 255)

go through parameters and if the checksum parameter is found, then verify it; f) if it is incorrect, then assume that transport connection is class 4 and drop it; g) if it is correct, then associate the TPDU with a transport connectiop; if the transport connection uses the checksum, it is correct: otherwise, it shall be considered as a protocol error.

,$pi

= 0 (modulo 255)

where is the number (see 13.2); (i.e. position) of an octet within the

;PDU ai L

,
i,

6.18 6.18.1

Frozen references Purpose shall be used in order to prevent re-use of a

is the value of octet in position isthe length of TPDU in octets.

This procedure

A transport connection agreed and discard the

entity which receives a TPDU for a transport for which the use of the checksum has been which does not satisfy the above formulae shall TPDU (see also note 2). and an answer has to

reference while TPDUs associated with the old use of the reference may still exist.
6.18.2 Procedure

When a spurious TPDU is received be sent, the transport er$y shall

a) if it. supports the checksum algorithm and the received TPDU contains a checksum parameter, include a checksum parameter in the answering TPDU; or b) in all other cases, not include a checksum in the answering TPDU. parameter

When a transport entity determines that a particular connection is released it shall place the reference which it has allocated to the connection in a frozen state according to the procedures of the class. While frozen, the reference shall not be re-used.
NOTE - The frozen reference procedure is necessary because retransmission or misordering can cause TPDUs bearing a reference to arrive at an entity after it has released the connection for which it allocated the reference. Retransmission, for example, can arise when the class includes either resynchronization (see 6.14) or retransmission on time-out (see 6.19). 6.18.2.1 Procedure for classes 0 and 2 specify * frozen

An entity not supporting ;he checksum may always suppose that a CR TPDU with class 4 proposed is correct and therefore negotiate down to a class lower than 4. NOTES 1 An efficient algorithm for determining the checksum parameters is given in annex B. 31
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NOTE - For consistency frozen as a local matter.

with other

classes,

references

may be

6.19.3

Procedure for class 4

6.18.2.2

Procedure

for classes

1 and 3

The procedure is specified in the procedures [see 12.2.1.2 j) and 12.2.1.3 g)]. except in the 6.20 6.20.1 Resequencing Purpose

The frozen reference procedure following cases (see note 1): a) when response

is used

the transport entity receives a DC TPDU in to a DR TPD!! which it has sent (see note 2);

b) When the transpoti entity sends a DR or ER TPDU in response to a CR TPD\I wnich it has `received (see note 3); c) when the transport entity has considered the connection to be released after the expiration of the TWR timer (see note 4); d) when the transport entity receives a DR or ER TPDU in response to a CR TPDU which it has sent;

The resequencing procedure is used in class 4 to cope with misordering of TPDUs by the network service provider. 6.20.2 TPDUs and parameters uses the following used TPDUs and parameters:

The procedure a) DTTPDU b)

TPDU-NR;

ED TPDU ED TPDU-NR. Procedure is specified in the procedures for class 4

e) when the reference

is zerr,. remains frozen 6.20.3

The period of time for which the reference shall be greater than the TWR time. NOTES

The procedure (see 12.2.3.5).
freezing the

1 However, even in these cases, for consistency reference may be done as a local decision. 2 When the `DC TPDU is received it is certain transport entity considers the connection released.

6.21
thit the other

Inactivity

control

6.21.1

Purpose

3 When the DR or ER TPDU is sent the peer tmn+port entity has not been informed of any reference assignmeni a.tyd thus cannot possibly make use of a reference (this includes the casa where a CC TPDU was sent, but was lost). .

The inactivity control procedure is used in class 4 to cope with unsignalled termination of a network connection when using CONS and the failure of a remote transport entity when using CONS or CLNS. 6.21.2 Procedure is specified in the procedures for class 4

4

In c) the transport entity has already reference for an adequate period.

effectively

frozsn

the

6.18.2.3

Procedure

for class 4

The procedure (see 12.2.3.3). 6.22 Treatment

The frozen reference procedure shall be used in class 4. The period for which the reference remains frozen shall be greater than L (see 12.2.1 .1.6). 6.19 6.19.1 Retransmission Purpose on time-out

of protocol

errors errors when operating

freatrnknt 6.22.1 over CONS 622.1 .l Purpose

of protocol

The procedure is used in class 4 to cope with unsignalled loss of TPDUs by the NS provider. 6.19.2 TPDUs used TPDUs:

The procedure for treatment of protocol classes to deal with invalid TPDUs. 6.22.1.2

errors is used in all

TPDUs and parameters used uses the following TPDUs and parameters:

The procedure

uses the following

The procedure

CR, CC, DR. DT, ED, AK TPDUs.

a) ER TPDU 32 reject cause;

*
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invalid TPDU; Treatment 6.22.2 over CLNS 6.22.2.1 Purpose of protocol errors is used to of protocol errors when operating

b) DRTPDU 6.22.1.3 reason code. Procedure

The procedure for treatment deal with invalid TPDUs. 6.22.2.2

A transport entity that receives a TPDU that can be associated to a transport connection and is invalid or constitutes a protocol error (see 3.2.16 and 3.2.17) shall take one of the following actions so as not to jeopardize any other transport connections not assigned to that network connection: a) transmit an ER TPDU; b) reset or close the network connection; c) invoke class. Under certain the TPDU. the release procedures or to the

TPDUs and parameters uses the following

used TPDUs and parameters:

The procedure a)

ER TPDU; reject cause; invalid TPDU;

appropriate

b)

DR TPDU; reason. Procedure

circumstances

it is also possible

to discard

6.22.2.3

If an ER TPDU is sent in class 0 it shall contain the octets of the invalid TPDU up to and including the octet where the error was detected (see notes 3, 4 and 5). If the TPDU cannot be associated with a particular transport connection the transport entity shall follow the procedures in 6.9. NOTES 1 In general, no further action is specified for the receiver of the ER TPDU but it is recommended that it initiates the release procedure appropriate to the class. If the ER TPDU has been received as an answer to a CR TPDU then the connection is regarded as released (see 6.6). 2 Care should be taken by a transport entity receiving several invalid TPDUs or ER TPDUs to avoid looping if the error is generated repeatedly. 3 If the invalid received TPDU is greater than the selected maximum TPDU size-inclusion in the invalid TPDU parameter of the ER TPDU may not be possible. 4 It is recommended that the sender of the ER TPDU starts an optional timer TS2 to ensure the release of the connection. If the timer expires, the transport entity shall initiate the release procedures appropriate to the class. The timer should be stopped when a DR TPDU or an N-DISCONNECT indication is received. 5 In classes other than 0, it is recommended that the invalid TPDU be alSo included in the ER TPDU.

Invalid TPDUs and protocol errors shall be ignored (no action and TPDU discarded, or responded to with an ER TPDU), except for the following case: a CC TPDU is received in which the class field does not specify class 4 sent CR TPDU has not yet been and a pr eviously acknowlec jged. In this case, the transport connection shall be terminz ited (see 6.7). NOTE - It is recommended that the Sender of the ER TPDU starts an optional timer TS2 to ensure the release of the connection. If the timer expires, the transport entity shall initiate the release procedure appropriate to class 4. The timer should be stopped
when a DR TPDU is received.

6.23 Splitting CONS 6.23.1

and recombining

when

operating

over

Purpose

This procedure is used only in class 4 to allow a transport connection to make use of multiple network connections to provide additional resilience against network failure, to increase throughput, or for other reasons. 6.23.2 Procedure

When this procedure is being used, a transport connection may be assigned (see 6.1) to multiple network connections (see note 1). TPDUs for the connection may be sent over any such network connection. If the use of class 4 is not accepted by the remote transport entity following the negotiation rules, then no network connection except that over which the CR TPDU was sent may have the transport connection assigned to it.
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NOTES 1 The resequencing function of class 4 (see 6.20) is used to ensure that TPDUs are processed in the correct sequence. 2 Either transport network connections entity may assign the connection to further of which it is the owner at any time during the

example, by sending connections, where cyclically.

successive TPDUs on successive the set of network connections

network is used

When splitting is ased the inactivity control procedure defines in 12.2.3.3 will not normally detect unsignalled network connection failure. Any method of monitoring network connections to detect such failure is a local matter.

life of the transport connection, provided the following constraints are respected: the initiator does not start splitting before having received the CC TPDU;
as soon as a new assignment is carried out it is recommended to send a TPDU on this network connection in order to make the r&mote entity aware of this assignment.

7

Protocol classes

Table 6 gives an overview of which elements of procedure are included in each class. In certain cases, the elements of procedure within different classes are not identical and, for this reason, table 6 cannot be considered as part of the definitive specification of the protocol.

A transport entity performing splitting should ensure that TPDUs are sent at intervals on each suppoRing network connection, for
3
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Table 6 - Allocation

of elements

of procedures 0

within classes

Protocol mechanism Assignment to network connection TPDU transfer Segmenting and reassembling Concatenation and separation Connection establishment Connection refusal Normal release Error release Association of TPDUs with transport connection TPDU numbering Expedited data transfer

T
4

2 3
X X X - X

Crossreference 6.1.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13

Variant or Option

4 CONS
X X X X X X

X X X X X X
X

AS
X X X X X X X
m
0 X

X X

Implicit Explicit

X

X

X X
Normal Extended Network Normal Network Expedited Confirmation receipt AK Use of selective acknowledgement Use of request acknowledgement o(4) of

X

X X
m a0
X

X

- X

X

m(l) gf
--

m
- 0 X

m
0 X

Reassignment after failure Retention and acknowledgement of TPDUs

X

0

a0 m
X

nesyncnronrzatron Multiplexing and demultiplexing Explicit flow control (with)

1 1

6.14 6.15

I

1,
I

T
X 0 X X X

X

x2 m

f--

zz
T

0

X

3

-I-

X

X X

X

X

m
0

m
0

X

+
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e

--t--
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8
8.1

Specification for class 0: Simple class
Functions of class 0

9 Specification recovery class
9.1

for class 1:

Basic error

Functions of class 1

Class 0 is designed to have minimum functionality. It provides only the functions needed for connection establishment with negotiation, data transfer with segmenting and protocol error reporting. Crass 0 provides transport connections with flow control based on the network service provided flow control, and disconnection based on the network service disconnection. 8.2 8.2.1 Procedures for class 0 applicable at ail times

Class 1 provides transport connections with flow control based on the network service provided flow control, error recovery, expedited data transfer, disconnection, and also the ability to support consecutive transport connections on a network connection. This class provides the functionality of class 0 plus the
by the Network

.

ability to recover after a failure signalled Service, without involving the TS-user. 9.2 9.2.1

Procedures

Procedures for class 1 Procedures applicable at all times

The transport entities shall use the following procedures: a) TPDU transfer (see 6.2); b) association (see 6.9); of TPDUs with transport connections

The transport entities shall use the following pr.ocedures: a) TPDU transfer (see 6.2); b) association of TPDU with transport connections (see 6.9): c) treatment of protocol errors (see 6.22); d) reassignment
after failure (see 6.12); after (see

c) treatment of protocol errors (see 6.22); d) error release (see 6.8). 8.2.2 Connection establishment

The transport entities shall use the following procedures: a) assignment to network connection (see 6.1.1); then b) connection establishment (see 6.5) appropriate, connection refusal (see 6.6); subject to the following constraints: 1) the CR and CC TPDUs shall contain no parameter fields in the variable part of the header other than those for TSAP-ID, maximum TPDU size, and preferred maximum TPDU size; 2) the CR and CC TPDUs shall not contain a data field. 8.2.3 Data transfer and and, if

e) resynchronization (see 6.14), or reassignment failure (see 6.12) together with resynchronization 6.14);

f)

concatenation and separation (see 6.4);

g) retention and acknowledgement of TPDUs (see 6.13); the variant used, AK or confirmation of receipt, shall be as selected during connection establishment (see the notes); h) frozen references (see 6.18).
NOTES 1 The negotiation of the variant of retention and acknowledgement of TPDUs procedure to be used over the transport connection has been designed such that if the initiator proposes the use of the AK variant (i.e. the mandatory

The transport entities shall use the segmenting reassembling procedure (see 6.3). 8.2.4 Release

implementation option), the responder has to accept use of this option and if the initiator proposes use of the confirmation of receipt
variant the responder is entitles to select use of the AK variant. 2 The AK variant makes use of AK TPDUs to release copies of retained DT TPDUs. The CDT parameter of AK TPDUs in class 1 is not significant, and is set to 1111. 3 The confirmation of receipt variant is restricted to this class and its use depends on the availability of the network layer receipt confirmation service', and the expected cost reduction.

The transport entities shall use the implicit variant of the normal release procedure (see 8.7.1.4). NOTE - The lifetime of the transport connection is directly correlated with the lifetime of the network connection.
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9.2.2

Connection

establishment procedures:

The transport

entities shall use the following to network connection

3 No other significance is attached to the ED-TPDU-NR parameter. It is recommended, but not essential, that the values used be consecutive modulo 128. 4 The use of RJ TPDUs during resynchlonization (see 6.14) can lead to retransmission. Thus, the receipt of a duplicate ED TPDU is

a) assignment

(see 6.1 .l); then and, if

possible. Such an ED TPDU is discarded. b) connection establishment (see 6.5) appropriate, connection refusal (see 6.6). 9.2.3 9.2.3.1 The sending procedures: Data transfer General transport entity shall use the following 9.2.4 Release variant of the

The transport entities shall use the explicit release procedure (see 6.7.1.5).

10 Specification class
10.1 Functions

for class 2:

Multiplexing

a) segmenting b) the normal (see 6.10). The receiving procedures:

(see 6.3); then format variant of DT TPDU numbering

of class

2

Class 2 provides transport connections with or without individual flow control; no e'rror detection or error recovery is provided. If the network connection resets or disconnects, the transport connection is terminated without the transport release procedure and the TS-user is informed. When explicit flow control is used, a credit mechanism is defined allowing the receiver to inform the sender of the exact amount of data he is willing to receive and that the expedited data transfer is available. 10.2 10.2.1 Procedures for class 2 applicable at all times procedures connection (see

transport

entity

shall

use

the

following

1) the normal format variant (see 6.10); then 2) reassembling (see 6.3).

of DT TPDU numbering

NOTE - The decision to issue an N-RESET request force the remote entity to carry out the resynchronization may be made on a local basis. 9.2.3.2 Expedited data

in order to (see 6.14)

The transport entities shall use either the network normal data or the network expedited variants of the expedited data transfer procedure (see 6.11) if their use has been selected during connection establishment (see note 1). The sending EDTPDU-NR transport entity shall not allocate the same to successive ED TPDUs (see notes 2 and 3).

Procedures

The transport

entities shall use the following of TPDUs with transport

a) association 6.9);

b) TPDU transfer When acknowledging an ED TPDU by sending an EA TPDU the transport entity shall put into the YR-EDTU-NR parameter of the EA TPDU the value received in the EDTPDU-NR parameter of the ED TPDU. NOTES
1 The negotiation of the variant of expedited data transfer procedure to be used over the transport connection has been designed such that if the initiator proposes the use of the network normal data variant (i.e. the mandatory implementation option), the responder has to accept use of this option and if the initiator proposes use of the network expedited variant, the responder is entitled to select use of the network normal data valiant. 2 This numbering enables the receiving transport entity to discard repeated ED TPDUs when resynchronlzation (see 6.14) has taken placa.

(see 6.2); errors (see 6.22.1): (see 6.4);

c)

treatment

of protocol

d) concatenation

and separation

e) error release (see 6.8). Additionally procedures: 1) 10.2.2 the transport entities may use me following

multiplexing Connection

and demultiplexing establishment

(see 6.15).

'
procedures: then

The transport

entities may use the following to network connection

a) assignment

(see S.l.lh
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b) connection establishment (see 6.5) and, if sppiicable, connection refusal (see 6.6). 10.2.3 control Data transfer when has been selected non-use of explicit flow

b) it an AK TPDU has previously been sent the value of the YR-TU-NR parameter shall not be lower than that in the previously sent AK TPDU; c) the sum of the YR-TU-NR and CDT fields shall not be less than the upper window edge allocated to the remote entity (see note 1). A transport entity which receives an AK TPDU shall consider the YR-TU-NR field as its new lower window edge, and the sum of YR-TU-NR and CDT as its new upper window edge. If either of these have been reduced or if the lower window edge has become more than one greater than the TPDU-NR of the last transmitted DT TPDU, this shall be treated as a protocol errOr,(See 6.22.1). A transport entity shall not send a DT TPDU with a TPDUNR outside of the transmit window (see notes 2 and 3). NOTES

If this option has been selected as a result of the connection establishment, the transport entities shall use the segmenting procedure (see 6.3). The TPDU-NR field of DT TPDUs take any value. is not significant and may

NOTE - Expedited data !ransier is not applicable (see 6.5). 10.2.4 Data transfer has been selected 10.2.4.1 The sending procedures: General transport entity shall use the followiny when use of explicit flow contra!

This means that credit reduction
2

is not applicable.

a) segmenting b)

(see 6.3): then (see 6.10). entity shall use the following

This means that a transport entity is required to stop sending if the TPDU-NR field of the next DT TPDU which would be sent would be the upper window edge. Sending of DT TPDU may be resumed if an AK TPDU is received which increases the upper window edge. 3 The rate at which a transport entity progresses the upper window edge allocated to its peer entity constrains the throughput attainable on the transport connection.

DT TPDU numbering transport

The receiving procedures:

1) DT TPDU numbering (see 6.10); if a DT TPDlJ is received which is out of sequer#ce it shall to treated as a protocol error , then 2) rea.ssembling (see 6.3).

10.2.4.3

Expedited

data

The variant of ?he DT TPDU numbering which is used by bo?h t:ansport entities sh all be that which was agreed at connection estah!is!lment. 10.2.4.2

The transport entities shall follow the network normal data variant of the expedited data transfer procedure in 6.11.1 if its use has been agreed during connection establishment. ED and EA TPDUs are not subject to the flow control procedures in 10.2.4.2. The ED-TPDU-NR and YR-ETDUNR fields of ED and EA TPDUs respectively are not significant and may take any value. 10.2.5 Release variant of the

FiOW

CGntiOl

The transport entities shall send an initial credit (which may be zero) in the CDT field of the CR or CC TPDU. This credi! represenis the initial value of the upper window edge allocated :o the peer entity. The transport entity that receives the CR or the CC TPDU shall consider its lower window edge as zero, and its upper window edge as the value of the CDT field in the received TPDU. In order to authorize the transmission of DT TPDUs, by its peer, a transport entity may transmit an AK TPDU at any time, subject to the following constraints: a) the YR-TU-NR parameter shall be at most one greater than the TPDU-NR field of the last received DT TPDU or shall be zero if no DT TPDU has been received;

The transport entities shall use the explicit release procedure in 6.7.1.

11 Specification and multiplexing
11.1 Functions

for class class

3:

Error recovery

of class 3

Class 3 provides the functionality of class 2 (with use of explicit flow control) plus the ability to recover after a failure signalled by the Network Layer without involving the TSuser. The mechanisms used allow the implementation to achieve this functionality of more flexible flow control. c also
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11.2 11.2.1

Procedures

for class 3 applicable at all times procedures: connections

2) Reassembling (see 6.3); duplicated TPDUs eliminated before reassembling is performed.

shall be

Procedures

The transport

entities shall use the following of TPDUs with transport

a) association (see 6.9);

NOTE - The use of RJ TPDUs (see 11.2.3.2) can lead to retransmission and reduction of credit. Thus the receipt of a DT TPDU which is a duplicate, or which is greater than or equal b the upper window ed9e allocated to the peer entity, is possible and is therefore not treated as a protocol error. 11.2.3.2 Use of an RJ TPDU

b) TPDU transfer acknowledgement 6.13); c) treatment

(see 6.2) and retention of TPDUs (AK variant only)

and (see

A transport entity may send an RJ TPDU at any time in order to invite retransmission or to reduce the upper window edge allocated to the peer entity (see note 1). When an RJ TPDU is sent, the following respected: constraints shall be

of protocol

errors (see 6.22.1); (see 6.4); with

d) concatenation e) reassignment resynchronization

and separation after failure (see 6.14);

(see 6.12), together

1) frozen references Additionally, procedure:

(see 6.18). entities may use the following

a) the YR-TU-NR parameter shall be at most one greater than the greatest value received in a previous DT TPDU, or shall be zero if no DT TPDU has yet been received (see note 2); b) if an AK or RJ TPDU has been sent previously the YR-TU-NR parameter shall not be lower than that in the AK or RJ TPDU sent previously. When a transport entity receives an RJ TPDU (see note 3):

the, transport

g) multiplexing 11.2.2

and demultiplexing establishment

(see 6.15).

Connection

The transport

entities shall use the following to netwoik connections

procedures: (see 6.1.1); then and, if

c) the next DT retransmitted, shall TPDU-NR parameter NR parameter of the

TPDU to be transmitted, or be that for which the value of the is equal to the value of the YR-TURJ TPDU;

a) assignment

b) connection establishment (see 6.5) apprbpriate, connection refusal (see 6.6). 11.2.3 11.2.3.1 Data transfer General transport entity shall use the

d) the sum of the values of the YR-TU-NR and CDT parameters of the RJ TPDU becomes the new upper window edge (see note 4). NOTES

1 An RJ TPDU can also be sent as part of the resynchronization (see 6.14) and reassignment after failure (see 6.12) procedures.
following 2 It is recommended that the YR-TV-NR parameter be equal to the TPDU-NR parameter of the next expected DT TPDU. 3 These rules are a subset of those specified for the case when an RJ TPDU is received during resynchronization (see 6.14) and reassignment after failure (see 6.12). 4 This means that an RJ TPDU can be used to reduce the upper window edge allocatec 10 the peer entity (credit reduction). 11.2.3.3 Flow control shall be as defined in 10.2.4.2, except that

The sending procedures:

a) segmenting

(see 6.3); then

b) DT TPDU numbering (see 6.10); after receipt of an RJ TPDU (see 11.2.3.2) the next DT TPDU to be sent may have a value which is not the previous value. of TPDU-NR plus one. The receiving procedures: transport entity shall use the following

The procedures 1) DT TPDU numbering (see 6.10); the TPDU-NR field of each received DT TPDU shall be treated as a protocol error if it exceeds the greatest value ret lived in a previous DT TPDU by more than one (see the note); then

a) a credit reduction may lead to the reception of a DT TPDU with a TPDU-NR parameter whose value is not, but would have been less than the upper window edge allocated to the remote entity prior to the credit reduction. This shall not be treated as a protocol error;
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b) receipt of an AK ? PDU which sets the lower window edae more than one areater than the TPDU-NR of the Ias: transmitted DT ?PDU shall not be treated as a protocol error, provided that all acknowledged DT TPDUs have been previously transmitted (see notes 1 and 2). NOTES This can only occur c!ufing retransmission following receipt of an RJ TPDU. 2
The transport sntiiy may either continue retransmisston as before or retransmit only those D? TPDUa, net acknowledged by the AK TPDU. in eilher case, copies of the acknowledged DT TPOUs need not be ret&nod
1

This dettsction of errors is made by extended use of the DT TPDU numbering of class 2 and class 3, by time-out mechanisms, and by additional procedures. Class a! detects signalled and unsignalied network failures (i.e. resets or disconnects or inactivity) and recovers from these failures by using time-out mechanisms. ihis Class detects using a checksum shall be available negotiation. and rc-covers from damaged TPDUs by mechanism. The checksum mechanism but its use or its non-use is subject to

This class a;so provides additional resilience against network failure and increased throughput capability by al!owing a transport connection to make use of multiple network connecGcns. 12.1.2 CLNS Functions of class 4 when operating over

11.2.3.4

Expedited

data

The transport entities shall follow the network normal data variant of the expedited da!ii transfer procedure in 6.11.1 if its use has been agreed during connection establishment. The sending transport entity shall not allocare the same EDTPDU-NY !c successive ED TPDUs. The receivirig transpor: entity shail transmit an EA TPDU with the same v&e in its YR-EDTU-NR parameter. If, and only if, this number is different from !hat of the ED TPDU perceived praviotisiy: ._, +ali it generate a T-EXPEDITED DATA indication to convey the data to the TS-user (see note 2!.
NOTES ! No other significance is attached to the ED-TPDU-NR parx~:eter. It is recommexled, but not essential that the values be sonsocutive modu!c 2": wtiere n is the number of bits of the paraameter.

Class 4 provides flow control between peer transport entities, the capability to detect and recover from errors which occur as a result of a low grade service available from the nttwork service provider and resilience from failure of the peer entity - the kind of errors to be detected include: TPDU loss, TPDU delivery out of sequence, TPDU duplication and TPDU corruption - these errors may affect control TPDUs as well as data TPDUs. The detection of errors is made by use of TPDU numbering on DT. AK, ED and EA TPDUs, by time-oui mechanisms and additional pracsdures such as the use of a checksum mechanism. The use of the checksum mechanism shall be available but its use or its non-use is subject to negotiation. 12.2 "12.2.1 12.2.1.1 Procedures for class 4 available at
all

2 This prooceduro enslures that the TS-user does not receive data r,?rrespondirg ?o t5e Same ED TPDU more than once.
11.2.4

Procedures

times

Timers used at all times at all times in

Release

The transport entities shall use the explicit release procedure in 6.7.1.

variant

of the

This sub-clause defines timers that.apply class 4. These timers are listed in table 7.

12 Specification for class 4: Error detection and recovery class
12.1 12.1.1 CONS Functions of class 4 of class
4

This International Standard does not define specific values for the timers, and. the derivations described in this sub&use are not mandatory. The values should be chosen so that the required quality of service can be provided, given the known characteristics of the network. Timers that apply only to specific under the appropriate procedure. procedures are defined

Functions

when

operating

over

.

12.2.1.1.1

NSDU lifetime (MLB M,&

Class 4 provides the functionality of class 3, plus the ability to detect and recover from lost, duplicated, or out of sequence TPDUs without involving the TS-user.

The Network Layer is assumed to provide, as an aspect of its grade of service, for a bound on the maximum lifetime of NSDUs in the network. This value may be different in each direction of trahsfer through a network between two transport entities. The values, for both directions of transfer, are assumed to be known by the transport entities. The
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maximum NSDU lifetime local-to-remote (M& is the maximum time which may elapse between the transmission of an NSDU from the local transport entity to the network and receipt of any copy of the NSDU from the network at the remote transport entity. The maximum NSDU lifetime remote-to-local (M& is the maximum time which may eiapse between the transmission of an NSDU from the remote transport entity to the network and receipt of any copy of the NSDU from the network at the local transport entity. 12.2.1.1.2 Expected maximum transit delay

12.2.1.1.5

Persistence

time

(Fl)
a bound for retransmit a which is not after credit

The local transport entity is assumed to provide the maximum time for which it may continue to TPDU requiring positive acknowledgement and outside the current transmit window, even reduction. This value is referred to as R.

( ELn, &)

The Network Layer is assumed to provide, as an aspect of its grade of service, an expected maximum transit delay for NSDUs in the network. This value may be different in each direction of transfer through a network between two transport entities. The values, for both directions of transfer, are assumed to be known by the transport entities. The expected maximum transit delay local-to-remote ( ELR) is the maximum delay suffered by all but a small proportion of NSDUs transferred through the network from the local transport entity to the remote transport entity. The expected maximum transit delay remote-to-local (ERL) is the maximum delay suffered by all but a small proportion of NSDUs transferred through the network from the remote' transport entity to the local transport entity. 12.2.1 .1.3 Acknowledgement time (AR, AL)

The value is clearly related to the time elapsed between the maximum number of retransmission, T1, and transmissions, N. It is not less than T1 l (N- 7) + x, where x is a small quantity to allow for additional internal delays, the granularity of the mechanism used to implement T1, etc. Because R is a bound, the exact value of x is unimportant as long as it is bounded and the value of a bound is known. 12.2.1.1.6 numbers Time bound of references and sequence

.

(L)

A bound for the maximum time between the decision to transmit a TPDU and the receipt of any acknowledgement relating to it (L) is given by:

L= MLLR+ MRL+ R+AR
where Mi_n is the NSDU lifetime local-to-remote; MR~ is the NSDU lifetime remote-to-local;

Any transport entity is assumed to provide a bound for the maximum time which can elapse between its receipt of a TPDU from the Network Layer and its transmission of the corresponding response. This value is referred to as A,. The corresponding time given by the remote transport entity is referred to as AR. 12.2.1 .1.4 Local retransmission time

R

is the persistence

time; time.

AR

is the remote acknowledgement

(Tf)
a bound before

It is necessary to wait for a period of time before reusing any reference or sequence number in order to avoid confusion when a TPDU referring to it is duplicated or delayed. The period of time during which the sequence numbers for DT TPDUs should be frozen is the period L, starting from the time when the sequence number has fallen below the lower window edge. NOTES

The local transport entity is assumed to maintain on the time it will wait for an acknowledgement retransmitting the TPDU. Its value is given by

Tl= ELR+ EnL+ AR+x
where

ELR is the expected
remote; ERR is the expected local:

maximum

transit

delay

local-to-

1 In practice, .the value of L may be too large. It may also be only a statistical figure at a certain confidence level. A smaller value may therefore be used where this still allows the required quality oft service to be provided. 2 The relationships between times discussed above are illustrated in figures 3 and 4.

maximum

transit

delay remote-to-

AR
X

is the remote acknowledgement is the local processing

time; 12.2.1.1.7 Inactivity timer (/`, In)

time for a TPDU. Any transport entity is assumed to provide a lower bound for the time which can elapse without receipt of a TPDU before it will initiate the release procedure to terminate the transport connection. This value is referred to as h. The corresponding time given by the remote transpott entity is referred to as IF).

NOTE - During connection establishment the value of AR is not known. In this case a suitable bound for T1 may be established either by estimating (or having a priori knowledge of) AR or by applying a suitable algorithm to the transport connection establishment delay 00s parameter.
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lt
Figure 3 - Interrelationship of times for the average case in class 4

R=Tt'(N-1)+x

L=MLR+MRL+R+A

Figure 4 -Interrelationship

of times for maximum

delay in class 4
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Table 7 -Time -. Symbol MLR Name NSDU lifetime iocal-toremote

parameters

related to the operation

of class 4

Definition A time bound for the maximum time which may elapse between the transmission of an NDSU by a local transport entity and the receipt of any copy of it by a remote peer entity. A time bound for the maximum time which may elapse between the transmission of an NSDU from a remote transport entity and the receipt of any copy of it by the local peer entity. A time bound for the maximum delay suffered by all but a small proportion NSDUs transferred from the local transport entity to a remote peer entity. A time bound for the maximum delay suffered by all but a small proportion NSDUs transferred from a remote peer entity to the local transport entity. of

MRL

z.SzU

lifetime remote-to-

ELR

Expected maximum transit delay local-to-remote Expected maximum transit delay remote-to-local Loca! acknowledgement time

ERL

of

AL

A time bound for the maximum time which can elapse between the receipt of a TPDU by the local transport entity from the network layer and the transmission of the corresponding acknowledgement. As AL, but for the remote entity.

Remote acknowledgement time TI Local retransmission time

A time bound for the maximum time the local transport acknowledgement before retransmitting a TPDU. A time bound for the maximum time the local transport transmit a TPDU that requires acknowledgement.

entity will wait for

R

Persistence

time

entity will continue

to

N L

Maximum number of transmissions Time bound on references and sequence numbers Local inactivity time

A time bound for the maximum number of times which the local transport will continue to transmit a TPDU that requires acknowledgement. A time bound for the maximum time between the transmission the receipt of any acknowledgement relating to it.

entity

of a TPDU and

IL

A lower bound for the time after which the local transport entity will, if it does not receive a TPDU, initiate the release procedure to terminate the transport connection. NOTE-This parameter is required for protection against unsignalled failures.

Remote inactivity time

A lower bound for the time after which the remote transport entity will, if it does not receive a TPDU, initiate the release procedure to terminate the transport connection. NOTE -This parameter is required for protection aga&t
unsignalled failures.

W

Window time

A time bound for the maximum time a transport retransmitting up-to-date window information.

entity will wait before

12.2.1.2 CONS _ The transport

General

procedures

when

operating

over

e) splitting and recombining 1) multiplexing

(see 6.23): (see 6.15); of TPDUs

and demuftiplexing and acknowledgement

entity shall use the following (see 6.2);

procedures: g) retention 6.13);

-_

(see

a) TPDU transfer b) association (see 6.9.1):.

of TPDUs

with transport

connections

h) frozen references

(see 6.18);

4 4

treatment checksum

of protocol errors (see 6.22.1); (see 6.17);

j) retransmission procedures; when a transport entity has some outstanding TPDUs that require acknowledgement, it will check that no 77 interval elapses without the arrival of a TPDU that @nowledges at least one of the outstanding TPDUs. If the timer expires, the first TPDU is retransmitted and the timer is
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restarted except if the TPDU to be retransmitted is a DT TPDU and is outside the transmit window due to credit reduction. Retransmission of a TPDU is subject to the availability of a network connection. If no network connection is available, and the retransmission timer runs out, then the retransmission counter may be incremented without sending the TPDU subject to the retransmission procedure. After Ntransmissions (i.e. N 7 retransmissions) it is assumed that useful two-way communication is no longer possible and the release procedure is used, and the TS-user is informed: NOTES 1 This procedure may be implemented by different means. For example: a) one interval is associated with each TPDU. If the timer expires the associated TPDU will be retransmitted and the timer T7 wili be restarted for all subsequent TPDUs; or b) one interval connection: is associated with each transport

b) association (see 6.9.1);

of

TPDUs

with transport

connections

d 4

treatment checksum

of protocol errors (see 6.22.2); (see 6.17); of TPDUs (see 6.13);

e) retention and acknowledgment

f)

frozen references

(see 6.18);

retransmission procedures; when a transport entity nas some outsta'nding TPDUs that require acknowledgment, it will check that no T7 interval elapses without the arrival of a TPDU that acknowledaes at least one of the outstanding TPDUs.

B)

1) if the transport entity transmits a TPDU requiring acknowledgement, it starts timer Tf; 2) if the transport entity receives a TPDU that acknowledges one of the TPDUs to be acknowledged, it restarts timer Tf unless the received TPDU is an AK which explicitly closes the transmit window;
3j

If the timer expires, except if the TPDU to be reiransmitted is a DT TPDU and it is outside the transmit window due to credit reduction, the first TPDU is retransmitted and the timer is restarted. After N transmissions (i.e. N - 7 retransmissions) it is assumed that useful two-way communication is no longer possible and the release procedure is used, and the TS-user is informed; NOTES 1 This procedure may be implemented by different means. For example: a) one interval is associated with each TPDU. If the timer expires the associated TPDU will be transmitted and the timer Tl will be restarted for all subsequent TPDUs; or b) one interval connection: is associated with each transport

if the transport entity receives a TPDU that acknowledges the last TPDU to be acknowledged, it stops timer Tf. For a decision whether the retransmission timer TI is maintained on a per TPDU or on a per transport connection basis, throughput considerations have td be taken into account. 2 For DT TPDUs it is a local choice to retransmit either only the first DT TPDU or all TPDUs waiting for an acknowledgement up to the upper window edge. 3 It is recommended that after N transmissions, the transport entity waits Tf + W + MRL in order to provide a higher possibility of receiving an acknowledgement before entering the release phase. For other TPDU types which may be retransmitted, it is recommended that after N transmissions the transport entity waits TI + MRL in order to provide a greater possibility of receiving the expected reply. 4 If use of selective acknowledgement has been negotiated, a selective acknowledgement implicitly identifies DT TPDUs not received. Since such a DT TPDU could be a lost DT TPDU, or simply a delayed DT TPDU, it is a local matter whether DT TPDUs not acknowledged in a selective acknowledgement should be retransmitted immediately. k) 12.2.1.3 The transport a) concatenation General and separation procedures (see 6.4). over CLNS

1) if the transport entity transmits a TPDU requiring acknowledgment, it starts timer TI; 2) if the transport entity receives a TPDU that acknowledges one of the TPDUs to be acknowledged, it restarts timer Tf unless the received TPDU is an AK which explicitly closes the transmit window; 3) if the transport entity receives a TPDU that acknowledges the last TPDU to be acknowledged, it stops timer TI. For a decision whether the retransmission timer T7 is maintained on a per TPDU or on a per transport connection basis, throughput considerations have to be taken into account. 2 For DT TPDUs it is a local choice to retransmit either only TPDUs waiting for an the' first DT TPDU or all acknowledgment up to the upper window edge. 3 It is recommended that after N transmissions, the transport entity waits TI + W + M,q to provide a higher possibility for receiving an acknowledgment before entering the release phase. For other TPDU types which may be retransmitted, it is recommended that after N transmissions th@ transport entity waits ~1 + MRL to provide an higher possibility of receiving the expected reply. 44
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4 If use of selective acknowledgement has been negotiated, a selective acknowledgement implicitly identifies DT TPDUs not received. Since such a DT TPDU could be a lost DT TPDU, or simply a delayed DT TPDU, it is a local matter whether DT

entity shall only acknowledge the duplicate CC TPDU according to the procedure in 12.2.2.2.b)l); 4) a CC TPDU may be received specifying a reference which is in the frozen state. The response to such a TPDU shall be a DR TPDU;
5) the retransmission procedures (see 12.2.1.2) used for both the CR TPDLJ and CC TPDU. are

TPDUs not acknowledged in a selective acknowledgement shouldbe retransmitted immediately. h) concatenation and separation (see 6.4). 12.2.2
12.2.2.1

Procedures

for connection

establishment

NOTE - After receiving a CR TPDU, it is recommended that the transport entity enforce a time limit upon the transport service user so that late acceptance of the transport connection will cot cause a delayed CC TPDU to be sent. 12.2.2.3

Timers used in connection establishment General procedures when operating over CLNS

There are no timers specific to connection establishment. 12.2.2.2 CONS General procedures when operating over

The transport entity shall use the procedure of connection establishment (see 6.5) and if appropriate connection refusal (see 6.6) together with the additional procedures:
1) a connection is not considered established until the

The transport entities shall use the following procedures: a) assignment to network connection (see 6.1.1); When a network connection to which the transport connection is assigned is released (NDISind received): 1) if a CC TPDU is awaited the initiator shall perform a new assignment according to 00s and the retransmission procedure (i.e. not sending the CR TPDU for more than N' TI); 2) if there is at least one other network connection to which the transport connection is assigned both initiator and acceptor may either perform a new assignment or continue operation using one of the remaining network connections; 3) if the transport connection becomes unassigned the acceptor may either perform a new assignment or wait (there is no risk of deadlock as either 77 or IL will be running); the initiator shall perform a new assignment (except in the closing state); b) connection establishment (see 6.5) and if appropriate connection refusal (see 6.6) together with the additional procedures: 1) a connection is not considered established until the successful completion of a 3-way TPDU exchange. The sender of a CR TPDU shall respond to the corresponding CC TPDU by immediately sending a DT, ED, DR, or AK TPDU; 2) as a result of duplication or transmission, a CR TPDU may be received specifying a source reference which is already in use with the sending transport entity. If the receiving transport entity is in the data transfer phase, having completed the 3-way TPDU exchange procedure, or is waiting for the TCONNECT response from the TS-user, the receiving transport entity shall discard such a TPDU. Otherwise a CC TPDU shall be transmitted. 3) as a result of duplication or retransmission, a CC TPDU may be received specifying a paired reference which is already in use. The receiving transport

successful completion of a three-way TPDU exchange. The sender of a CR TPDU shall resoond to the corresponding CC TPDU by immediately &ding a DT, ED, DR or AK TPDU;
2) as a result of duplication or retransmission, a CR TPDU mav be received soecifvina a sou'ce reference which is already in use with the seeding transport entity. If the receiving transport entity is in the data transfer TPDU phase, having completed the three-way exchange procedure, or is waiting for the T-CONNECT response from the TS-user, the receiving transport entity shall discard such a TPDU. Otherwise a CC TPDU shall be transmitted: 3) as a result of duplication or retransmission, a CC TPDU may be received specifying a paired reference which is already in use. The receiving transport entity shall onlv acknowledae the duolicate CC TPDU according'to the procedire in 12.2.i.3.1); 4) a CC TPDU may be received specifying a reference which is in the frozen state. The response to such a TPDU shall be a DR TPDU;

5) the retransmission procedures (see 12.2.1.3) are used for both the CR TPDU and CC TPDU. NOTE - After receiving a CR TPDU, it is recommended that the transport entity enforce a time limit upon the transport service user so that late acceptance of the transport connection will not cause a delayed CC TPDU to be sent.
12.2.3 12.2.3.1 12.2.3.1.1 Procedures for data transfer

Timers used in data transfer Timers used in data transfer when operating

over CONS

c
The data transfer procedures usi one additional timer: a) Window timer (VV) 45
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A transport entity maintains a timer interval to ensure that theie is a bdund on the maximum interval between window updates.
NOTE - A suitable upper bound value for W is such that W < /R-EL+ It is recommended that the value for W be sufficiently less than (/R T ELR) such that the inactivity control procedure in 12.2.3.3 can be operated having regard to the possibility of TPDU loss. 12.2.3.1.2 Timers used in data transfer when operating

TPDU loss. The window syncnrsnization procedures (see 12.2.3.6) ensure that this requirement is met.
NOTE - It is likely that the release procedure initiated due to the expiration of the inactivity timer will fail, as such expiration indicates probable failure of the supporting network connection or of the remote transport entity.

12.2.3.4 12.2.3.4.1

Expedited data Expedited data when operating over CONS

over CLNS
The data transfer procedures use one additional timer:

The transport entities shall follow the network normal data variant of the expedited data transfer procedures (see
6.1 l.l), if the use of the transport expedited service has been agreed during connection establishment. option

a) Window timer

(w)
The ED TPDU shall have a TPDU-NR which is allocated from a separate sequence space from that of the DT TPDUs. A transpoi entity shall allocate the sequence number zero
of the first ED TPDU which it transmits

A transport

entity maintains a timer interval to ensure that there is a bound on the maximum interval between window updates. NOTE - A suitable upper band value for Wis such that W < 1~ - ELR II is recommended that the value for W be sufficiently less than (/R - ELR) such that the inactivity control procedure in 12.2.3.3 can be operated having regard to the possibility of TPDU loss. 12.2.3.2 General procedures for data transfer

to the ED TPDU-NR

&r a transport connection. For subsequent ED TPDUs sent on the same transport connection, the transport entity shall allocate a sequence number one greater than the previous one. Modulo 2? arithmetic shall be used when normal formats have been selected and modulo 9' arithmetic shall be used when extended formats have been selected. The receiving transport entity shall transmit an EA TPDU with the same sequence number in its YR-EDTU-NR field. If this number is one greater than in the previously received in-sequence ED TPDU, the receiving transport entity shalt transfer the data in the ED TPDU to the TS-user. If a transport entity does not receive an EA TPDU in acknowledgement to an ED TPDU it shall follow the retransmission procedures (see note and 12.2.1.2). The sender of an ED TPDU shall not send any new DT TPDU created from a T-DATA request subsequent to the TEXPEDITED DATA request, until it receives the EA TPDU.
NOTE - This procedure ensures that ED TPDUs are delivered to the TS-user in sequence and that the TS-user does not receive data corresponding to the same ED TPDU more than once. Also it guarantees the arrival of the ED TPDU before any data subsequently sent by the TS user.

The transport entities shall use the following procedures: a) inactivity control (see 6.21); b) expedited data (see 6.11); c) Explicit flow control (see 6.16). The sending transport entity shall procedures in the following order: 1) segmenting (see 6.3); 2) DT TPDU numbering (see 6.10). The receiving transport entity shall use the following procedures in the following order: DT TPDU numbering (see 6.10); resequencing (see 6.20); use the following

12.2.3.4.2 reassembling (see 6.3). Inactivity control

Expedited data when operating over CLNS

12.2.3.3

The transport entities shall follow the expedited data transfer procedures in 6.11.2, if the use of the transport expedited data service option has been agreed during connection establishment. The ED TPDU shall have a TPDU-NR which is allocated from a separate sequence space from that of the DT TPDUs.

If the interval of the inactivity timer I expires without receipt of some TPDU, the transport entity shall initiate the release procedures. To prevent expiration of the remote transport entity's inactivity timer when no data is being sent, the local transport entity must send AK TPDUs at suitable intervals in the absence of data, having regard to the probability of
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A transport entity shall allocate the sequence number zero to the ED TPDU-NR of the first ED TPDU which it transmits for a transport connection. For subsequent ED TPDUs sent on the same transport connection, the transport entity shall allocate a sequence number one greater than the previous one. Modulo Z7 arithmetic shall be used when normal formats have been selected and modulo 23' arithmetic shall be used when extended formats have been selected. The receiving transport entity shall transmit an EA TPDU with the same sequence number in its YR-EDTU-NR field. If this number is one greater than in the previously received in-sequence ED TPDU, the receiving transport entity shall transfer the data in the ED TPDU to the TS-user. If a transport entity does not receive an EA TPDU in acknowledgment to an ED TPDU it shall follow the retransmission procedures (see note and 12.2.1.3). The sender of an ED TPDU shall not send any new DT TPDU created from a T-DATA request subsequent to the TEXPEDITED DATA request, until it receives the EA TPDU.
NOTE - This procedure ensures that ED TPDUs are delivered to the TS-user in sequence and that the TS-user does not receive data corresponding to the same ED TPDU more than once. Also it guarantees the arrival of the ED TPDU before any data

Duplicated DT TPDUs shall be acknowledged, since the duplicated TPDU may be the result of a retransmission resulting from the loss of an AK TPDU. The data contained discarded.
12.2.3.6

in a duplicated

DT TPDU shall be

Explicit flow control

The transport entities shall send an initial credit (which may take the value 0) in the CDT field of the CR TPDU or CC TPDU. This credit represents the initial value of the upper window edge of the peer entity. The transport entity which receives the CR TPDU or CC TPDU shall consider its lower window edge as zero and its upper window edge as the value in the CDT field in the received TPDU. In order to authorize the transmission of DT TPDUs by its peer, a transport entity may transmit an AK TPDU at any time. The sequence number of an AK TPDU shall not exceed the sequence number of the next expected DT TPDU, i.e. it shall not be greater than the highest sequence number of a received DT TPDU, plus one. A transport entity may send a duplicate containing the same sequence number, subsequence number field at any time. A transport entity may increase or decrease window edge at any time. AK TPDU CDT, and

subsequently sent by the TS user.
12.2.3.5 Resequencing

The receiving transport entity shall deliver all DT TPDUs to the TS-user in the order specified by the sequence number field. DT TPDUs received out-of-sequence but within the transmit window shall not be delivered to the TS-user until all insequence TPDUs have been received. DT TPDUs received out-of-sequence and outside the transmit window shall be discarded but may result in transmission of an AK TPDU with up-to-date window information (see 12.2.3.8). If the selective acknowledgement option has been agreed to at connection establishment, DT TPDUs that have been selectively acknowledged shall be retained by the receiving transport entity until delivered to the TS-user. They shall be retained even if the selectively acknowledged DT TPDUs later fall outside the transmit window due to a subsequent credit reduction.
NOTE - It is recommended that the transport entity sending the AK TPDU maintains a bound on the number of times a DT TPDU is selectively acknowledged in order to reduce the processing at the transport entity receiving the AK TPDU.

the upper

A transport entity which receives an AK TPDU shall consider the value of the YR-TU-NR field as its new lower window edge if it is greater than any previously received in a YR-TU-NR field, and the sum of YR-TU-NR and CDT as its new upper window edge subject to the procedures for sequencing AK TPDUs (see 12.2.3.8). A transport entity shall not transmit or retransmit a DT TPDU with a sequence number outside the transmit window. 12.2.3.7 Sequencing of received AK TPDUs

To allow a receiving transport entity to properly sequence a series of AK TPDUs that all contain the same sequence number and thereby use the correct CDT value, AK TPDUs may contain a subsequence parameter. For the purpose of determining the correct sequence of AK TPDUs, the absence of the subsequence parameter shall be equivalent to the value of the parameter set to zero. An AK TPDW is defined to be in sequence if

Duplicate TPDUs can be detected because the sequence number matches that of previously received TPDUs. Sequence numbers sha!l not be reused for the period L after their previous use. Otherwise, a new, valid TPDU could be confused with a duplicated TPDU which had previously been received and acknowledged.

a) the sequence number is greater than any previously received AK TPDU, or b) the sequence number is equal to the highett in any previously received AK TPDU. and the subsequence parameter is greater than in any previously received AK TPDU having the same value for YR-TU-NR field, or 47
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c) the sequence number and subsequence parameter are both equal to the highest in any previously received AK TPDU and the credit field is greater than or equal to that in any previously received AK TPDU having the same YR-TU-NR field. When the receiving transport entity recognizes sequence AK TPDU it shall discard it. 12.2.3.8 12.2.3.8.1 Procedures for transmission of AK TPDUs an out-of-

NOTE - The use of the procedures defined in 12.2.3.8.3 and 12.2.3.8.4 is optional for any transport entity. The protocol operates correctly either with or without these procedures which are defined to enhance the efficiency of its operation.

12.2.3.8.2 TPDUs

Sequence

control

for

transmission

of AK

of AK TPDUs

Transmission

To allow the receiving transport entity to process AK TPDUs in the correct sequence, as described in 12.2.3.7. the subsequence parameter shall be included following reduction of CDT. If the value of the subsequence number to be transmitted is zero, then the parameter should be omitted. The value of the subsequence parameter, if used, shall be zero (either explicitly or by absence of the parameter) if the sequence number is greater than the parameter in previous AK TPDUs, sent by the transport entity. If the sequence number is the same as the previous AK TPDU sent and the CDT field is equal to or greater than the CDT field in the previous AK TPDU sent then the subsequence parameter, if used, shall be equal to that in the previously sent AK TPDU. If the sequence number is the same as the previous AK TPDU sent and the CDT field is less than the value of the CDT field in the previous AK TPDU sent then the subsequence parameter, if used, shall be one greater than the value in the previous AK TPDU.
NOTE - If a transport entity never reduces number. credit, then it does not

An in-sequence DT TPDU shall be acknowledged within time AL, by the transmission of an AK TPDU whose YR-TUNR parameter is set to at least the sequence number of the If the selective received DT TPDU plus one. acknowledgement option has been agreed to at connection establishment, out of sequence DT TPDUs may also be acknowledged within time AL. The YR-TU-NR parameter shall be set to one greater than the highest sequence number of, an in-sequence DT TPDU and the selective acknowledgement parameter will be appropriately set. An AK TPDU shall be transmitted window information if containing up-to-date

a) a DT TPDU is received whose sequence number is lower than the lower window edge, but greater than or equal to the lower window edge minus the maximum credit value ever given for this transport connection, or b) a DT TPDU is received whose sequence number is above the current upper window edge, but following credit reduction is within the upper window edge which has been granted and then withdrawn. NOTES I A simpler implementation may send an AK TPDU upon reception of any DT TPDU outside the transmit window. 2
The procedure a) is required correctly recovered, i.e. when retransmits it following non-receipt The procedure b) is required so that loss of an AK TPDU is the sender of the DT TPDU of an acknowledgement. due to the possibility of loss of the

need to use the subsequence

12.2.3.8.3 to zero

Retransmission

of AK TPDUs

after CDT set

Due to the possibility of loss of AK TPDUs, the upper window edge as perceived by the transport entity transmitting an AK TPDU may differ from that perceived by the intended recipient. To avoid the possibility of extra delay, the retransmission procedure (see 12.2.1.2 and 12.2.1.3) can be followed for an AK TPDU, if it opens the transmit window which has previously been closed by sending an AK TPDU with CDT field set to zero. The retransmission procedure, if used, terminates procedure in 12.2.3.8.1 is used when and the

3

AK TPDU indicating the upper window edge reduction, which could otherwise cause incorrect termination of the transport connection. 4 Wherever procedures &) and b) are invoked and selective acknowledgement option is being used, the selective acknowledgement parameters, if required, of the AK TPDU will be appropriately set. A transport entity shall not allow an interval W to pass without the transmission of an AK TPDU. If the transport entity is not using the procedure following setting CDT to zero (see 12.2.3.8.3) or reduction of the upper window edge (see 12.2.3.8.4), and does not have to acknowledge receipt of any DT TPDU, then it shall achieve this by retransmission of the most recent AK TPDU, with up-to-date window information.

a) an AK TPDU is received containing the flow control confirmation parameter, whose lower window edge and your subsequence fields are equal to the sequence number and subsequence number in the retained AK TPDU and whose credit field is not zero; b) an AK TPDU is transmitted with a sequence number higher than that in the retained AK TPDU, due to reception of a DT TPDU whose sequence number is equal to the lower window edge; c) N transmissions of the retained AtGTPDU have taken place. In this case the transport entity shall continue to transmit the AK TPDU at an interval of W.
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An AK TPDU which is subject to the retransmission procedure shall not contain the flow control confirmation parameter. If it is required to transmit this parameter concurrently, an additional AK TPDU shall be transmitted having the same values in the sequence, subsequence (if applicable) and credit fields. 12.2.3.8.4 Retransmission procedures reduction of the upper window edge following

The rules for determining whether to apply the retransmission procedure to an AK TPDU may be expressed alternatively as follows. Let
LWE I lower window edge UWE = upper window edge KUWE = lower bound on upper window edge held by remote transport entity. The retransmission procedure is to be applied whenever: (UWE > LWE) and (KUWE = LWE) i.e. when the window is opened and it is not known definitely that the remote transport entity is aware of this. KUWE is maintained as follows:

This sub-clause specifies the procedure for retransmission of AK TPDUs after a transport entity has reduced the upper window edge (see 12.2.3.6). This procedure is used until the lower window edge exceeds the highest value of the upper window edge ever transmitted (i.e. the value existing at the time of credit reduction, unless a higher value is retained from a previous credit reduction). The retransmission Procedure should be toflowed for any AK TPDU which increases the upper window edge, unless it is known that the remote transport entity has an open window. This is known if - a flow control confirmation (FCC) parameter has been received corresponding to an AK TPDU transmitted following the most recent credit reduction, and; - this FCC parameter conveys an upper window edge value (i.e. the sum of the lower window edge and credit fields) which is greater than the lower window edge of the transmitted AK TPDU. This retransmission procedure for any particular AK TPDU shall terminate when a) an AK TPDU is received containing the flow control ccndrmaticn parameter,, whose lower window edge and your subsequence fields are equal to the lower window edge and subsequence number in the retained AK TPDU; or b) N transmissions of the retained AK TPDU have taken place. In this case the transport entity shall continue to transmit the AK TPDU at an interval of W. An AK TPDU which is subject to the retransmission procedure shall not contain iiia !low control confirmation parameter. If it is required to transmit !his parameter concurrently, an additional AK TPDU shall be transmitted having the same values in the sequence, subsequence (if applicable) and credit fields. NOTE - Retransmission of AK TPDUs is normally not necessary, except following explicit closing of the window (i.e. transmission of an AK TPDU witfr CDT field set to zero). If data are available for tf'ans+nission: the retransmission procedure for DT TPDUs will ensure tfiat an AK TPDU is received granting further credit where this is available; following credit reduction, this may no longer be because retransmission may be inhibited by the credit reduction. The rules described in this clause avoid extra delay.
SO.

When credit is reduced, KUWE is set to LWE. Subsequently, it is increased only upon receipt of a valid flow control confirmation (i.e. one which matches the retained lower window edge and subsequence). In this case KUWE is set to the implied upper window edge of the flow control confirmation, i.e. the sum of its lower window edge and your credit fields. By using this method, it can be ensured that KUWE is always less than or equal to the actual upper window edge used by the transmitter of DT TPDUs.

12.2.3.9

Use of flow control confirmation parameter

An AK TPDU containing a flow control confirmation parameter may be transmitted at any time. The lower window edge, your subsequence and your credit fields shall be set to the same values as the corresponding fields in the most recently received in-sequence AK TPDU. An AK TPDU containing a flow control parameter should be transmitted whenever confirmation

a) a duplicate AK TPDU is received, with the value of YR-TU-NR,. CDT, and subsequence fields equal to the most recently received in sequence AK TPDU, but not itself containing the flow control confirmation parameter; b) an AK TPDU is received which increases the upper window edge but not the lower window edge, and the upper window edge was formerly equal to the lower window edge; or c) an AK TPDU is received which increases the upper window edge but not the lower window edge, and the lower window edge is lower than the highest value of the upper window edge received and subsequently reduced (i.e. following credit reduction). 12.2.4 12.2.4.1 Procedures
for release

Timers used for release

There are no timers used only for release.
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12.2.4.2

General

procedures

for release variant of normal

The transport entity shall use the explicit release (see 6.7).

Although the retransmission procedure also apply to the DR TPDU in the release phase, the transport entity may however consider that the transport connection has been released if it would be necessary to open a new network connection in order to retransmit the DR TPDU.
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13 Structure and encoding of TPDUs
13.1 Validity

Table 8 specifies those TPDUs which are valid for each class and the code for each TPDU. Table 8 - TPDU codes

__

0011 1001 1010

0000
xXxX XxXx

__
__ Key: xxxx (bits 4 to 1): used to signal the CDT (set to 0000 in classes 0 to 1). zzn (bits 4 to 1): used to signal CDT in classes 2,3,4 set to

1111in

class 1, establishment (classes 1,

y (bit 1): used to signal ROA if the request acknowledgement procedure has been agreed at connection This bit shall be set to 0 if the request acknowledgement procedure has not been agreed. NF: Not available when the non-explicit flow control option is selected. NRC: Not available when the receipt confirmation option is selected.

3, 4 only).

NOTE -These codes are already in use in related protocols defined by standards organizations other than CCITT and lSC/lEC.

13.2

Structure number of octets. The octets in a TPDU are numbered The bits in an octet are numbered from 1 to 8, where bit

All the transport protocol data units (TPDUs) shall contain an integral starting from 1 and increasing in the order they are put into an NDSU. 1 is the lowest order bit. When consecutive NOTES 51 octets are used to represent

a binary number, the lower octet number has the most significant

values
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The numbering of bits within an octet is a convention local to this international Standard. The use of the terms `high order' and `low order' is common to this International Standard and to adjacent layer standards. The use of the above conventions does not affect the order of bit transmission on a serial communications link. As described in 6.2.3, both transport entities respect these bit and octet ordering conventions, thus allowing communication to take place. In this clause the encoding of TPDUs is represented in the following form: a) octets are shown with the lowest numbered octet to the left; higher numbered octets being further to the right;

b) within an octet, bits are shown with bit 6 to the left and bit 1 to the tight.

TPDUs shall contain, in the following order: a) the header, comprising 1) the length indicator (LI) field; 2) the fixed part; 3) the variable part, if present; b) the data field, if present. The structure is illustrated below: Octets 1 Li 2 3 4 ... n n+l ._. p
p+1 .. .

end

Fixed pati

_
13.2.1

-

-

-

-

-

1 _ header . -

Variable part

I -

Data Field

I

-

-

_

-

Length indicator field

The field is contained in the first octet of the TPDUs. The length is indicated by a binary number, with a maximum value of 254 (1111 1110). The length indicated shall be the header length in octets including parameters, but excluding the length indicator field and user data, if any. The value 255 (1111 1111) is reserved for possible extensions. If the lenqth indicated exceeds or is equal to the size of the NS-user data which is present, this is a protocol error. 13.2.2 13.2.2.1 Fixed part General

The fixed pari contains frequently occurring parameters including the code of the TPDU. The length and the structure of the fixed part ave defined by the TPDU code and in certain cases by the protocol class and the formats in use (normal or extended). If any of the parameters of the fixed part have an invalid value, or if the fixed part cannot be contained within the header (as defined by LI), this is a protocol error.
NOTE - In general, the TPDU code defines the fixed palt unambiguously. However, different variants may exist for the same TPDU code (See normal and extended formats).

13.2.2.2

TPDU code

This field contains the TPDU code and is contained in octet 2 of the header. It is used to define the structure of the remaining header. This field is a full octet except in the following cases: 1110 xxxx 1101 xxxx Connection request Connection confirm
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1111 0101
0110

oooy XxXx
xxxx

Data Reject Data acknowledgement

where xxxx (bits 4 to 1) is used to signal the CDT. y (bit 1) is used to signal ROA if the request acknowledgement only). Only those codes defined in 13.1 are valid. 13.2.3 has been agreed at connection establishment (class

1, 3, 4

Variable part
used parameters. If the variable part is present, it shall contain one or more

The variable part is used to define less frequently parameters.

NOTE -The number of parameters that may be contained in the variable part is indicated by the length of the variable part which is LI minus the length of the fixed part. Each parameter Octets contained within the variable part is structured Sits 6 7 6 5 4 as follows: 3 2 1

n+l

Parameter

code

n+2 n+3 n+2+m

I

Parameter

length indication

(for example

m)

I

Parameter

value

The parameter

code field is coded in binary.

NOTE - Without extensions, it provides a maximum number of 255 different parameters. However, as noted below, bits 8 and 7 cannot take every possible value, so the practical maximum number of different parameters is less. Parameter code 1111 1111 is reserved for possible extensions of the parameter code. The parameter length indication indicates the length, in octets, of the parameter value field.

NOTE - The length is indicated by a binary number, m, with a theoretical maximum value of 255. The practical maximum value of m is lower. For example, in the case of a single parameter contained within the variable part, two octets are required for the parameter code and the parameter length indication itself. Thus, the value of m is limited to 248. For larger frxed parts of the header and for each succeeding parameter, the maximum value of m decreases. The parameter No parameter value field contains the value of the parameter code uses bits 8 and 7 with the value 00. identified in the parameter code field,

The parameters defined in the variable part may be in any order. If any parameter is duplicated then the last value shall be used. A parameter not defined in this International Standard shall be treated as a protocol error in any received TPDU except a CR TPDU; in a CR TPDU it shall be ignored. A called TSAP-ID parameter in a CC TPDU with a length indicator set to zero shall be treated as having the "nil selector value" (see ISO/IEC 74963, 9.5.2). If the responding transport entity selects a class for which a parameter of the CR TPDU is not defined, it may ignore this parameter, except if it is the class and option parameter, or the alternative protocol class parameter which shall always be interpreted, A parameter defined in this International Standard but having an invalid value shall be treated as a protocol error in any received TPDU except a CR TPDU. In a CR TPDU it shall be treated as a protocol error if it is either the class and option parameter or the alternative class parameter; bits 8 to 7, and bits 6 to 1, if not meaningful for the class proposed, of the additional options parameter shall be ignored; otherwise it shall be either ignored or treated as a protocol error.

c
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13.2.3.1

Checksum

parameter

(class 4 only) in a CR TPDU

All TPDU types may contain a 1Bbit checksum parameter in their variable part. This parameter shall be present and shall be present in all other TPDUs except when the non-use of checksum option is selected. Parameter Parameter Parameter 13.2.4 code: !ength: value: 1100 0011 2 Result of checksum algorithm; this algorithm is specified in 6.17.

Data field transparent request user data. (CR) TPDU 128 octets. Resrricrions on its size are noted for each TPDU.

This field contains 13.3 Connection

The length of the CR TPDU shall not exceed 13.3.1 structure

The structure

of the CR TPDU shall be as follows: 3 4 5 6 7 6 P p+l end

13.3.2

bl

See 1X2.1. 13.3.3 Fixed payt (octets 2 to 7) of this part shall contain: Connection request code: 1110. Bits 8 to 5 of octet 2; class). Bi!s 4 to 1 of octet 2;

The structure a) CR: b) CD]`. cj

lniiia! credit allocation Set to zero; Reference

(set to 0000 in classes 0 and 1 when specified as preferred

DST-REF:

d) SRC-REF: connection:

selected

by the transport

entity

initiating

the CR TPDU

to identify

the requested

transport

e) CLASS and OPTION: Bits 8 to 5 of octet 7 define the preferred transport protocol class to be operated requested transport connection. When operating over CONS, this field shall take one of the following values: 0000 0001 0010 0011 0100 Class 0 Class 1 Class 2 Class 3 Class 4 over CLNS, this field shall take the value 0100 to indicate class 4.

over the

When operating
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The CR TPDU contains if required.

the first choice of class in the fixed part.

Second

and subsequent

choices are listed in the variable

part

Bits 4 to 1 of octet 7 define options to be used on the requested

transport

connection

as follows:

BIT

OPTION

= 0 Always
= 0 Always = 0 Use of normal formats = 1 Use of extended in all classes in classes 2,3, and 4

formats

= 0 Use of explicit flow control in class 2 = 1 No use of explicit flow control in class 2
I

J
and may therefore take any value.

Bits related to options particular NOTES

to a class are not meaningful

if that class is not proposed

1 The connection establishment procedure (see 6.5) does not pen-nit a given CR TPDU to request use of transport expedited data transfer service (additional option parameter) and not use of explicit flow control in class 2 (bit 1 = 1).
2

Bits 4 to 1 are always zero in class 0 and have no meaning. Variable part (octets 8 to p) in the variable part:

13.3.4

The following

parameters Service code:

are permitted Access

a) Transport Parameter

Point Identifier

(TSAP-ID) of the calling TSAP of the called TSAP Standard

1100 0001 for the identifier 1100 0010 for the identifier

Parameter Parameter If a TSAP-ID

length: value:

not defined identifier

in this International

of the calling or called TSAP respectively. it may be returned in the confirmation.

is given in the request

a

b) TPDU size This parameter defines the proposed maximum TPDU size (in octets including transport connection. The coding of this parameter is Parameter Parameter Parameter code: length: value: 8 4 2 1 192 096 048 024 512 256 128 octets octets octets octets octets octets octets (not allowed (not allowed in class 0) in class 0) 1100 0000 1 octet the header) to be used over the requested

0000 1101 0000 1100 0000 1011 0000 1010 0000 1001 0000 1000 00000111 Default value:

0000 0111 (128 octets).
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c)

Preferred

maximum

TPDU size the proposed maximum TPDU size (in octets including the header) to be used over the requested

This parameter defines transport connection.

The coding of this parameter Parame?er Parameter Parameter Code: length: vaiue:

is:

11110000 up to 4 a binary value. The binary value indicates the maximum TPDU size, expressed as a multiple of 128 octets [see 6.5.4 m) and 6.5.5 m)]. This binary value shall be greater than or equal to 1. (cot used if class 0 is the preferred 1100 0100 1 octet 0000 0001 class)

d) Version

number

Parame?or code: Parameter Parameter pefauit length:

value fie!d:

va!ue:

0000 0001 (not used in class 0). (not used is class 0 is the preferred class)

e) Protection Thus parameter Parameter Parameter

parameters

is user defined. code: length: 1100 0101 user defined

`r'arame?er va!~;c: user dcfiped. t) Checksum (used only if class 4 is the preferred class ) (see 13.2.3.1) class 4, even if the checksum selection parameter is used

This ijarameter shall always be present in a CR TPDU requesting to reiuest non-use of the check&m facility. gj Addjtional option selection (not used if class 0 is the preferred to be made as io whether

class) options are to be used.

Tilis parameter Parameter Paramoter Parameter

defines the selection code: iength: value: BIT 6 1100 0110 1

or noi additional

1 I

I
OPTION

I-----=o Non-use 5 =o 4 Non-use =O Non-use

t = 1 Use of request acknowledgement

in class 1,3,4 in classes in class 4 in class 4 1,3, 4

of request acknowledgement acknowledgement

= 1 Use of selective

of selective

acknowledgement in class 1

= 1 Use of network expedited

of network expedited

in class 1 6
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= 1 Use of receipt confirmation
=O =O

in class 1

Use of explicit AK variant in class 1 l&bit checksum defined in 6.17 shall be used in class 4 defined in 6.17 shall not be used in class 4 expedited data transfer service service

= 1 16-bit checksum = 1 Use of transport =O Non-use

of transport

expedited

data transfer

Default value:

0000 0001. upon receipt. and may therefore take any

Bits 8 and 7 shall be set to zero when sending the TPDU and ignored Bits related value. to options particular to a class are not meaningful

if that class is not proposed

h)

Alternative Parameter Parameter

protocol cl&s(es) code: length: 1100 0111 n

(not used if class 0 is the preferred

class or when operating

over CLNS)

Parameter value: (i.e. no alternative

Encoded as a sequence of single octets; each encoded option selections permitted). time (used only if class 4 is the preferred class)

as for octet 7 but with bits 4 to 1 set to zero

i)

Acknowledgement

This parameter conveys the maximum acknowledgement is not subject to negotiation (see 12.2.1 .1.3). Parameter Parameter Parameter code: length: value: 1000 0101 2

time AL to the remote transport

entity.

It is an indication

only, and

n, a binary number where n is the maximum class)

acknowledgement

time, expressed

in milliseconds.

W

Throughput Parameter Parameter Parameter

(not used if class 0 is the preferred code: length: value: 1000 1001 12 or 24

1st 12 octets: maximum throughput, as follows: First 3 octets: target value, calling-called user direction Second 3 octets: minimum acceptable, calling-called user direction Third 3 octets: target value, called-calling user direction Fourth 3 octets: minimum acceptable, called-calling user direction 2nd 12 octets (optional): average throughput, as follows: Fifth 3 octets: target value, calling-called user direction Sixth 3 octets: minimum acceptable, calling-called user direction Seventh 3 octets: target value, called-calling user direction Eighth 3 octets: minimum acceptable, called-calling user direction Where average throughput is omitted, expressed in octets per second. m) Residual it is considered to have the same value as the maximum throughput. Values are

error rate (not used if class 0 is the preferred

class)

*
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Parameter Parameter Parameter

code:

1000 0110

length:. 3 value:

1 st octet: target value, power of 10 2nd octet: minimum acceptable, power of 10 3rd octet: TSDU size of interest, expressed as a power of 2 n) Priority (not used if class 0 is the preferred Parameter Parameter Parameter code: length: value: 1000 0111 2 integer (0 is the highest priority) class) class)

p) Transit delay (not used if class 0 is the preferred Parameter Parameter Parameter code: length: value: 1000 1000 6

First 2 octets: target value, Second 2 octets: maximum Third 2 octets: target value, Fourth 2 octets: maximum Values are expressed q) Reassignment may be used)

calling-called user direction acceptable, calling-called user direction called-calling user direction acceptable, called-calling user direction and are based upon a TSDU size of 128 octets. class; if class 4 is preferred and class 3 is an alternate, it

in milliseconds,

time (not used if class 0 or 2 is the preferred

This parameter conveys the Time to Try Reassignment reassignment after failure (see 6.12). Parameter Parameter Parameter r) Inactivity code: length: value: 1000 1011 2 n, a binary number

(TTR) which

shall

be used when

following

the procedure

for

where n is the TTR value expressed or selected class) entity.

in seconds.

timer (used only if class 4 is the preferred conveys the inactivity

This parameter negotiation

timer IL to the remote

transport

It is an indication

only, and is not subject

to

(see 12.2.1 .1.7). code: length: value: 1111 0010 4 a binary value. This binary value indicates the inactivity time expressed in milliseconds.

Parameter Parameter Parameter 13.3.5

User data (octets p + 1 to the end) in class 0, and are optional in other classes. Where permitted, they shall not exceed 32 octets.

No user data are permitted
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13.4 13.4.1

Connection Structure

Confirm

(CC) TPDU

The structure of the CC TPDU shall be as follows: 1 2 CC CDT 1101 xxxx 3 4 5 6 7 CLASS OPTION 8 P p+l end User Data

I
DST-FIEF

I
SRC-REF

LI

Variable pati

I

I

13.4.2

LI

See 13.2.1. 13.4.3 Fixed part (octets 2 to 7)

The fixed part shall contain a) CC: Connection b) CDT: c) confirm code: 1101. Bits 8 to 5 of octet 2;

Initial credit allocation Reference Reference

(set to 0000 in classes 0 and 1). Bits 4 to 1 of octet 2; the requested transport entity connection initiating at the remote transport the CC TPDU entity; the confirmed transport

DST-REF:

identifying selected

d) SRC-REF: connection;

by the transport

to identify

e) CLASS OPTION: connection according 13.4.4 Variable

Defines the selected transport protocol to the negotiation rules specified in 6.5.

class and option to be operated

over the accepted

transport

part (octets 8 to p) establishment). Parameters

The parameters are defined in 13.3.4 and are subject to the constraints stated in 6.5 (connection ruled out by selection of an alternative class and option shall not be present. 13.4.5 User data (octets p + 1 to the end)

No user data are permitted in class 0. and are optional in the other classes. Where permitted, The user data are subject to the constraints of the negotiation rules (see 6.5) 13.5 13.5.1 Disconnect Structure of the DR TPDU shall be as follows: 2 3 4 5 6 7 8 P Request (DR) TPDU

they shall not exceed

32 octets.

The structure 1

p+l

end

LI

DR 1000 0000

DST-REF

I

SRC-REF

I

REASON

Variable

I

I

pati

User Data

13.5.2

LI

See 13.2.1.
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13.5.3

Fixed part (octets 2 to 7)

The fixed part shall contain a) DR: b) Disconnect request code: identifying identifying 1000 0000; the transport the transport connection connection at the remote transport at the transport entity; the TPDU. Value zero when

DST-REF:

Reference

c) SRC-REF: Reference reference is unassigned; d) REASON: values: The following 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) The following 12) 13) 14) 15) Defines

entity initiating

the reason

for disconnecting

the transport

connection.

This field shall take one of the following

values

may be used for classes

1 to 4:

128 + 0: Normal disconnect 128 + 1: Remote transport

initiated by session entity entity congestion at connect request time class(es) not supported]

l l 28 + 2: Connection
128 + 3: Duplicate

negotiation

failed [i.e. proposed

source reference references

detected for the same pair of NSAPs.

128 + 4: Mismatched

128 + 5: Protocol error 128 + 6: Not used 128 + 7: Reference 128 + 8: Connection overflow request refused on this network connection

128 + 9: Not used 128 + 10: Header or parameter length invalid.

values can be used for all classes: 0: Reason not specified 1: Congestion at TSAP

l 2: Session entity not attached to TSAP
`3: Address unknown.

NOTE - Reasons marked with an asterisk (`) may be reported to the TS-user as persistent, other reasons as transient. 13.5.4 Variable part (octets 8 to p)

The variable

may contain allowing additional code: 1110 0000 the maximum agreed TPDU size information related to the clearing of the connection;

a) a parameter Parameter

Parameter length: any value provided that the length of the DR TPDU does not exceed or 128 when the DR TPDU is used during the connection refusal procedure. Parameter b) checksum 13.5.5 value: additional information; the content of this field is user defined.

(see 13.2.3.1).

User data (octets p.+ 1 to the end) of this datt is not guaranteed

This field shall not exceed 64 octets and is used to carry TS-user data. The successful transfer by the transport protocol. When a DR TPDU is used in class 0 it shall not contain this field.
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13.6

Disconnect

Confirm

(DC) TPDU

This TPDU shall not be used in class 0. 13.6.1 Structure of the DC TPDU shall be as follows: 2 3 4 5 6 7 P

The structurs 1

I
DC 1100 0000

DST-REF

I

SRC-REF

I

I
Variable part

13.6.2

LI

See 13.2.1. 13.6.3 Fixed part (octets 2 to 6)

The fixed part shall contain

4 b) cl
13.6.4

DC: Disconnect DST-REF: SRC-REF: Variable

confirm code:

1100 0000;

see 13.4.3; see 13.4.3. part parameter if the condition defined in 13.2.3.1 applies.

The variable part shall contain the checksum 13.7 13.7.1 Depending Data (DT) TPDU Structure

on the class and the option the DT TPDU shall have one of the following

structures:

a) Normal format for classes 0 and 1 1 2 3 TPDU-NR and EOT 4 5 . .. end

LI

D; `ROA 1111 OOOy

User data

I

b) Normal format for classes 2,3 and 4 1 2 3 4 5 TPDU-NR and EOT 6 P P+l end

I
LI c DT ROA 1111 oooy

DST-REF

I
I

Variable part

User data

I
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c)

Extended 1

format for use in classes 2, 3 and 4 when selected 2 3 4

during connection 9 P

establishment p+t end

5. 6, 7, 6 TPDU-NR and EOT

I
LI DT ROA 1111 oooy

I
DST-REF

Variable part

User data

I

I

13.7.2

LI

See 13.2.1. 13.7.3

Fixed part

The fixed part shall contain
a)

DT: Data transfer

code:

bits 8 to 5 shall be set to 1111.

Bits 4 to 2 shall be set to zero. procedures has not been agreed during

b) ROA: Request of acknowledgement mark: If the request acknowledgement connection establishment, bit 1 shall be set to 0 in all DT TPDUs.

When the request acknowledgement procedure has been agreed during connection establishment, bit 1 (ROA) is used to request acknowledgement in classes 1, 3, and 4. When set to one, ROA indicates that the sending transport entity requests an acknowledgement from the receiving transport entity. Otherwise ROA is set to zero. c) DST-REF: See 13.4.3; DT TPDU sequence

d) EOT: When set to ONE, it indicates that the current DT TPDU is the last data unit of a complete (end of TSDU). EOT is bit 8 of octet 3 in class 0 and 1 and bit 8 of octet 5 for classes 2, 3 and 4;

e) TPDU-NR: TPDU send sequence number (zero in class 0). May take any value in class 2 without explicit flow control. TPDU-NR is bits 7 to 1 of octet 3 for classes 0 and 1, bits 7 to 1 of octet 5 for normal formats in classes 2 3, and 4 and bits 7 to 1 of octet 5 together with octets 6, 7 and 8 for extended format. NOTE - Depending on the class, the fixed pan of the DT TPDU uses the following octets: classes 0 and 1: octets 2 to 3;
classes 2, 3,4 (normal format): octets 2 to 5; classes 2, 3,4 (extended format): octets 2 to 8.

13.7.4

Variable

part parameter if the condition defined in 13.2.3.1 applies.

The variable 13.7.5

part shall contain the checksum

User data field
data of the TSDU being transmitted.

This field contains

5 octets (normal header format) or 8 octets (extended

NOTE -The length of this field is limited to the negotiated TPDU size for this transport connection minus 3 octets in classes 0 and 1, and minus header format) in the other classes. The variable part, if present, may further reduce the size of the user data field.

13.8

Expedited data (ED) TPDU
flow control option is selected or when the

This ED TPDU shall not be used in class 0 or in class 2 when the no explicit expedited data transfer service has not been selected for the connection.

13.8.1
Depending

Structure
on the format negotiated at connection establishment 62 the ED TPDU shall have one of the following

*
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a) Normal format (classes 1, 2, 3, 4) 1 2 3 4 5 5 P' p+t end

LI

I ED
0001 0000

DST-REF

I
I

ED TPDU-NR and EOT

Variable

User data

I

pati
during connection 9 P establishment) P+l end

b) Extended 1

format (for use in classes 2, 3 and 4 when selected 2 3 4

5, 5, 7, 5
ED TPDU-NR and EOT

I
LI
ED 0001 0000

DST-REF

I
I

Variable

User data

I

pad

13.8.2

LI

See 13.2.1. 13.8.3 Fixed part

The fixed part shall contain a) ED: Expedited b) DST-REF: data code: 0001 0000;

see 13.4.3; is used in classes 1, 3 and 4 and may take any formats bits 7 to 1 of octet 5 together with octets

c) ED TPDU-NR: Expedited TPDU identification number. ED TPDU-NR value in class 2. For normal formats bits 7 to 1 of octet 5 and for extended 6. 7 and 5;
d) EOT: End of TSDU always set to 1 (bit 8 of octet 5).
2

NOTE - Depending on the format the fixed part shall be either octets 13.8.4 Variable

to 5 or 2 to 8.

part
parameter if the condition defined in 13.2.3.1 applies.

The variable part shall contain the checksum 13.8.5 User data field an expedited

This field contains

TSDU (1 to 16 octets).

13.9

Data acknowledgement (AK) TPDU
nor for class 1 when the

This TPDU shall not be used in class 0 or in class 2 when the no explicit flow control option is selected, network receipt confirmation option is selected. 13.9.1 Depending

Structure
on the class and option agreed the AK TPDU shall have one of the following structures:

a) Normal format (classes 1, 1 2

2, 3, 4)
3 .4 5 6 P

I
LI AK CDT 0110 zzzz

DST-REF

I
I

YR-TU-NR

Variable

part

I
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b) Extended format (for use in classes 2, 3 and 4 when selected during connection establishment) 1 LI 2
I

3 DST-REF

4

5,6,7,8 YR-TU-NR

9

10

11

.

p

AK 0110 0000

I
I

CDT

Variable part

I
13.9.2 LI

See 13.2.1. 13.9.3 Fixed part

The fixed part shall contain (in octets 2 to 5 when normal format is used or in octets 2 to 10) the following parameters: a) AK: Acknowledgement code: 0110; b) CDT: Credit value (set to 1111 in class 1). CDT is bits 4 to 1 of octet 2 for normal formats and octets 9 and 10 for extended formats; c) DST-REF: See 13.4.3; d) YR-TU-NR: Sequence number indicating the next expected DT TPDU number. For normal formats, bits 7 to 1 of octet 5; bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, bits 7 to 1 of octet 5 together with octets 6, 7 and 8; bit 8 of octet 5 is not significant and shall take the value 0. 13.9.4 Variable part

The variable part contains the following parameters: a) Checksum if the condition in 13.2.3.1 applies; b) Subsequence number when optionally used under the conditions defined in class 4. This parameter is used to ensure that AK TPDUs are processed in the correct sequence. If it is absent, this is equivalent to transmitting the parameter with a value of zero. Parameter code: 1000 1010 Parameter length: 2 Parameter value: 16-bit subsequence number;

4 Flow control confirmation when optionally used under the conditions defined in class 4. This parameter contains a copy
of the information received in an AK TPDU, to allow the transmitter of the AK TPDU to be certain of the state of the receiving transport entity (see 12.2.3.9). Parameter code: 1000 1100 Parameter length: 8 Parameter value: defined as follows: 1) Lower window edge (32 bits). Bit 8 of octet 1 of the parameter value field is set to zero, the remainder contains the YR-TU-NR value of the received AK TPDU. When normal format has been selected, only the least significant seven bits (bits 1 to 7 of octet 4 of the parameter value field) of this field are significant. 2) Your subsequence (16 bits). Contains the value of the subsequence parameter of the received AK TPDU, or zero if this parameter was not present.
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3) Your credit (16 bits). Contains the value of the CDT field of the received AK TPDU. When normal format has been selected, only the least significant four bits (bits 1 to 4 of octet 2 of the Your Credit field) of this field are significant.

d) Selective acknowledgement parameters when optionally used, under conditions defined in class 4, to acknowledge out of sequence DT TPDUs received by the entity transmitting the AK TPDU. All consecutive DT TPDUs received shall be acknowledged by a single block. Different groups of DT TPDUs that are consecutive within group but not across groups shall be acknowledged using separate blocks (e.g., if DT TPDU numbers 3, 4, 5, 7, 8, 12, 13, 14, 15 and 17 are received with 3 the first out-of-sequence DT TPDU, then 3. 4, 5 form one group, 7, 8 another and 12, 13, 14, 15 a third, and 17 a fourth. The corresponding blocks would be (3, 5), (7, 8), (12, 15) and (17, 17)). Parameter Parameter code: length: 1000 1111 2n (normal format) or 8n (extended format) octets where n is the number if distinct blocks being selectively acknowledged. This length is constrained by the maximum header size of 254 octets. In the normal format, the first octet of a pair of two octets shall represent the lower edge and the second octet the upper edge of each block. Bit 8 of each octet is set to zero, the remainder represents the sequence number of the edge. In the extended format, the first four octets of a set of eight octets represent the lower edge and the subsequent four octets represent the upper edge. For each edge of four octets, Bit 8 of the first octet is not significant and is set to 0; bits 7 to 1 of the first octet together with the second, third and fourth octets represent the sequence number. Whether normal or extended formats are used, each set of two or eight octets may be repeated many times as there are blocks to,be acknowledged. 13.10 Expedited data acknowledgement (EA) TPDU option is selected, or when the as

Parameter

value:

The EA TPDU shall not be used for class 0, or for class 2 when the "no explicit flow control" expedited data transfer service has not been selected for the connection. 13.10.1 Depending a) Structure on the option (normal (classes 2 or extended format) the TPDU structure shall be:

Normal format 1

1, 2,3, 4) 3 4 5 6 P

I LI
EA 0010 0000

I
DST-FIEF Y R-EDTU-NR Variable part

I
b) Extended 1 format

I
during connection 9 establishment)

(for use in classes 2. 3 and 4 if selected 2 3 4

5, 6, 7, 8

P

I
LI EA 0010 0000

DST-REF

I

YR-EDTU-NR

Variable

part

I

I

&

13.10.2

LI

See 13.2.1. 13.10.3 Fixed part (in octets 2 to 5 when normal format is used or in octets 2 to 8) the following code: 0010 0000; parameters: 2

The fixed part shall contain a) EA: Expedited

acknowledgement
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b) DST-REF: See 13.4.3; c) YR-EDTU-NR: identification of the ED TPDU being acknowledged. May take any value in class 2. For normal formats bits 7 to 1 of octet 5; bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, bits 7 to 1 of octet 5 together with octets 6, 7 and 8; bit 8 of octet 5 is not significant and shall take the value 0. 13.10.4
Variable part

The variable part may contain the checksum parameter (see 13.2.3.1).
13.11 Reject (RJ) TPDU

The RJ TPDU shall not be used in classes 0,2, and 4.
13.11.1 Structure

The RJ TPDU shall have one of the following formats: a) Normal format (classes 1 and 3) 1 2 3 4 5

I
LI RJ CDT 0101 2222

DST-REF

I
I

YR-TU-NR

I

b) Extended format (for use in class 3 if selected during connection establishment)
1

2

3

4

5, 6, 7, 8

9

10

I
LI RJ 0101 0000

DST-REF

I
I

YR-TU-NR

CDT

I

13.11.2

LI

See 13.2.1. 13.11.3 Fixed part

The fixed part shall contain (in octets 2 to 5 when normal format is used or in octets 2 to 10) the following parameters: a) RJ: Reject code: 0101. Bits 8 to 5 of octet 2; b) CDT: Credit value (set to 1111 in class 1). For normal formats bits 4 to 1 of octet 2 and for extended formats octets 9 and 10: c) DST-REF: See 13.4.3; d) YR-TU-NR: Sequence number indicating the next expected TPDU from which retransmission should occur. For normal formats, bits 7 to 1 of octet 5, bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, bits 7 to 1 of octet 5 together with octets 6, 7 and 8; bit 8 of octet 5 is not significant and shall.take the value 0. 13.11.4 Variable part

There is no variable part for this TPDU type.
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13.12
13.12.1 1

TPDU error (ER) TPDU
Structure

I
13.12.2 13.12.3

1
LI ER 01110000

I
DST-REF

I

I

REJECT CAUSE

Variable part

LI

See 13.2.1. Fixed part parameters:

The fixed part shall contain the following

4 b) c)

ER: TPDU Error code: DST-REF: REJECT 0000 0000 0000 0000 See 13.4.3; CAUSE:

0111 0000;

0000 ooot 0010 0011 part

Reason not specified Invalid parameter code Invalid TPDU type Invalid parameter value.

13.12.4

Variable

The variable a)

part may contain

the following

parameters:

Invalid TPDU Parameter Parameter code: length: 1100 0001 number of octets of the value field TPDU header up to and including the octet which caused the

Parameter value: contains the bit pattern of the rejected rejection. This parameter is mandatory in class 0. b) Checksum This parameter shall be present if the condition

in 13.2.3.1 applies
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Section Three: Conformance
NOTES

14 Conformance
14.1 A system claiming to implement the procedures specified in this International Standard shall comply with the requirements in 14.2 to 14.5. 14.2 The system shall implement class 0 or class 2 or both. This implies operation over CONS.

1 The procedures for classes 0 to 4 are clauses 8 to 12 respectively. The procedures elements of procedures specified in clause 6. 2 The requirement in 14.5 e) indicates 128 octets is always implemented.

specified in refer to the

that TPDU size of

14.6

Claims of conformance shall state

14.3 If the system implements class 3 or class 4. it shall also implement class 2. If the system implements implement class 0.
14.4

a) which class or classes of protocol are implemented;

class

1.

it shall also

b) whether class connectionless-mode

4

can be operated network service:

over

the

14.5 For each class which the system imple,ment, the system shall be capable of

claims

to

c) whether the system is capable responding to CR TPDUs or both;

of initiating

or

a) initiating CR TPDUs or responding to CR TPDUs with CC TPDUs or both; b) responding to any other TPDU and operating network service in accordance with the procedures for the class; c) operating all the procedures for the class listed as mandatory in table 9; d) operating those procedures for the class listed as optional in table 9 for which conformance is claimed; e) handling all TPDUs of lengths up to the lesser value of 1) the maximum length for the class if the preferred maximum TPDU size parameter is not implemented [see 1334b)]; 2) the maximum for which conformance is claimed (see note 2);

d) which of the procedures listed as optional in table 9 are implemented; e) for each class, the maximum size of TPDU implemented [see 13.3.4 b) and 13.3.4 c)]. If the oreferred maximum TPDU size oarameter is not implemented the value shall be `chosen from the following list and all values in the list which are less than this maximum shall be implemented: 128, 256, 512, 1 024, 2 048, 4 096 or 8 192 octets. If the preferred maximum TPDU size parameter is implemented, any maximum size of TPDU that is a multiple of 128 octets is allowed. All values, except 0. that are a multiple of 128 octets, less than the maximum claimed shall be implemented. 14.7 The supplier of a protocol implementation which is claimed to conform to this International Standard shall complete a copy of the PIGS proforma provided in Annex D and shall provide the information necessary to identify both the supplier and the implementation.
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Table 9 - Provision

of options

Procedure TPDU with checksum TPDU without checksum Expedited data transfer No expedited data transfer Flow control in class 2 No flow control in class 2 Normal formats Extended formats Use of receipt confirmation in class 1 No use of receipt confirmation in class 1 Use of network expedited in class 1 No use of network expedited in class 1 Use of selective class 4 acknowledgement in

class 0 not applicable mandatory not applicable mandatory not applicable not applicable mandatory not applicable not applicable not applicable

class 1 not applicable mandatory mandatory mandatory not applicable not applicable mandatory not applicable optional mandatory

class 2 not applicable mandatory mandatory mandatory mandatory optional mandatory optional not applicable not applicable

class 3 not applicable mandatory mandatory mandatory not applicable not applicable mandatory optional not applicable not applicable

class 4 mandatory optional mandatory mandatory ___-not applicable not applicable -mandatory optional not applicable not applicable

-

not applicable not applicable

optional mandatory

not applicable not applicable

not applicable not applicable

not applicable not applicable

not applicable

not applicable

not applicable

not applicable

optional

Use of request of acknowledgement in classes 1, 3. 4

not applicable

optional

not applicable

optional

optional
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Annex A
(normative)

State tables
a) one action constituted of a list of any number of outgoing events (none, one, or more) given by their abbreviated name defined in table A.3 followed by the abbreviated name of the resultant state (see table A.2); b) conditional actions separated by a semi-colon (;). Each conditional action contains a predicate followed by a colon (:) and by an action as defined in a). The predicates are boolean expressions given by their abbreviated name and defined in the clauses related to the state tables of each class. Only the action corresponding to the predicate which is true shall be taken. A.2.5 The state tables also include giving explanatory using materials; notation:

A.1

General

This annex provides a more precise description of the protocol. In the event of a discrepancy between the description in these tables and that contained in the text, the text takes precedence. The state tables also define the mapping between and protocol events that TS-users can expect. service

This annex describes the transport protocol in terms of state tables. The state tables show the state of a transport connection, the events that occur in the protocol, the actions taken and the resultant state. The state tables describe only !he operation of a single trar.sport connection. They do not necessarily describe all possible combinations of seauences of events at transport and network service boundary, nor do they describe'the exact mapping between TPDUs and NSDUs.

a) informal comments b) references (note number);

to notes

the following

c) references to other actions defined in separate using the following notation: [action number].

tables

A.2

Conventions A.3 Tables

A.2.1 Incoming events are represented in the state . tables by their abbreviated name, as defined in table A.1 A.2.2 States are :epresented in the abbreviated name, as defined in table A.2. tables by their

Table A.1 specifies that names and abbreviated names of the incoming events, classified as TS-user events, NSprovider events or TPDU events. Table A.2 specifies the states. the names and abbreviated names of

A.2.3 The intersection of each state and event which is invalid is left blank. The actioti to be taken in this case shall be one of !he following: a) for an event related to the transport coming from the KS-user), take no action; service (i.e.

Table A.3 specifies the names and abbreviated names of the outgoing events classified as TS-provider events, NSuser events or TPDU events.

b) for an event related to a received TPDU, follow the procedure for treatment of protocol errors (see 6.22) if the state of the supporting network connection makes it possible; c) for an event falling into neither of the above categories (including those which are impossible by the definition of the behaviour of the transport entity or NSprovider), take no action. A.2.4 At each intersection valid the state tables specify one of the following: of state and event which is an action which may include

A.4

State tables for classes 0 and 2
description of a of class 0 or class

This clause provides a more precise transport entity for a transport connection 2. The description uses predicates defined specific actions defined in table A.5.

in table

A.4, and

The description does not include a complete specification of the data transfer procedures but makes reference to the specification of the classes (see clause 8 and 10). Table A.6 gives the state automata for classes 0 and 2.
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Table A.1 - incoming Abbreviated name

events

1

I

I

r TPDU
Ldu I TU"

I TDnl I
TPDU TPDU TPDU TPDU
TPDLl -_

] Connection Reauest TPDU Pnnnch-.+;P.n P~~~~~ TPDU vvI III=c,IvII "onfirm ~~~ _______~Disconnect Request TPDU Disconnect Confirm TPDU Data Acknowledgement TPDU Expedited Data Acknowledaement Data TPDU

--___

DR DC AK EA

TPDU

I

_T

ii

-RJ

1 TPDU -_-.

j TPDU

Table A.2 - States Abbreviated name

1

Name

I

WFNC-R WFCC-R WBCL-R OPEN-R OPEN-WR CLOSING-R CLOSING-WR WFTRESP-WR WBCL-WR

1Wait for network connection and reassignment in progress [ Wait for CC TPDU and reassignment in progress
) Wait before releasing and reassignment in progress 1Open and reassignment in progress Open and wait for reassignment Release in progress and reassignment in progress Release in progress and wait for reassignment Wait for T-CONNECT response and wait for reassignment 1 Wait before releasing and wait for reassignment Wait before open complete (CC is unacknowledged) Wait before open complete and wait for reassignment Wait before open complete and release in progress ldem and wait for reassignment Waiting for acknowledgement of CC TPDU Waiting for frozen reference time

]

WBOC
WBOC-WR CLOSING BOC CLOSING BOC-WR AKWAIT REFWAIT

-----A

f
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Table A.3 - Outgoing Abbreviated name Category

event Name

NDlSreq NRSTresp

I
_

NS-user NS-user TPDU TPDU TPDU TPDU TPDU ___I_ TPDU TPDU TPDU TPDU TPDU Connection Request TPDU Connection Confirm TPDU Disconnect Request TPC Disconr - lect Confirm TPDU __---Da& Acknowledgement TPDU -__ Expedited Data Acknowledgement --_I_ TPDU Data TPDU Expedited Data TPDU TPDU Error TPDU ____ Reject TPDU

AK EA DT ED ER RJ

I

~~

1

3

--___I-

Table A.4 - Predicates -_T

for classes Description

0 and 2

---

Name

--

-..I__ PO PI -i \----__ P2 P3 P4 P5 P6 P7 P8 P9 P10

T-CONNECT re.quest unacceptable ___-_ UJeptable CR TPDU No network connedion available Network connection available and open Network connection available and open in progress Class in class 0 (class selected in CC) Unacceptable CC Class is class 2 Acceptable CC Class 4 CR Local choice

.

Table A.5 - Specific actions for classes 0 and 2 Name --W---Description If the network connection is not used by another transport connection assigned to it, it may be disconnected. (See 6.1.3 note 3) See 6.22 (receipt of an ER TPDU) See data transfer procedures of the class See expedited data transfer procedure of the class An N-RESET response has to be issued once for the network connection if the network connection has not been released. In class 0, an N-DISCONNECT request has to be issued. The DC TPDU contains a SRC-REF field set to zero and a DST-REF field set to the SRC-REF of the DR TPDU received.

121 [3] [I 121

F31

i *
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Table A.6 - State table for classes State WFNC Event TCONreq WFCC WBCL (Class 2 only)

0 and 2 CLOSING (Class 2 only)

OPEN

WFTRESP

CLOSED PO: TDlSind CLOSED; P2: NCONreq WFNC; P3: CR WFCC; P4: WFNC

P5: NDlSreq CLOSED; P7: DR CLOSING

CL:&0

CLOSING

WFTRESP

CLOSED; not Pl: TCONind

TDlSind

P7: DC ' [II TDlSisd CLOSED CLOSED DOES NOT EXIST IN CLASS 0 :2) CLOSED P7: (1) CLOSED CLOSING

[I!
CLOSED DC

(11

TDlSind CLOSED

DC CLOSED

CLOSED

CC

P8: TCONconf OPEN; P6 and P5: TDlSind NDlSreq CLOSED; P6 and P7: TDlSind DR CLOSING

P5 : (3) NDlSreq CLOSED; P7: DR CLOSING

DR CLOSED

4K EA

DOES NOT EXIST IN CLASS o (2)

CLOSED

1 [3]OPEN I 1 [4]OPEN
[4] OPEN 131OPEN TDlSind [l] CLOSED [l] CLOSED (2)

1 CLOSING 1 CLOSING
CLOSING CLOSING (2)

1
CLOSED

DOES NOT EXIST IN CLASS o (2)

1
CLOSED CLOSED CLOSED

DOES NOT EXIST IN CLASS o (2)

An ER TPDU should be sent in certain cases (see 6.6) If received it should be processed as a protocol error (see 6.22). A CR with class 2 has been sent and a CC class 0 is received, If DC is not available (i.e. class 0 only implemented) or SRC-REF is zero. This happens only when the preferred class of the CR TPDU received is class 4. 73
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A.5

State tables for classes

1 and 3
description of a of class 1 or 3.

Specific actions are defined in table additional notes are given in table A.9.

A.8

and

specific

This clause provides a more precise transport entity for a transport connection The description use the predicates

defined in table A.7.

The description does not include a complete specification of the data transfer but makes reference to the specification of the classes (see clauses 9 and 11). Table A.10 gives the state automata for classes 1 and 3. for classes 1 and 3

Table A.7 - Predicates Name PO Pl P2

P3 P4 P5 P6 P7 P8 P9 PlO

Description T-CONNECT Request unacceptable No available network connection can be used for assignment or reassignment ___A network connection can be used for assignment or reassignment; the network connection opening is in progress _ A network connection can be used for assignment or reassignment; the network connection is open ____ TTR timer has previously run out Local choice Initiator of the transport connection Unacceptable CR TPDU TWR is running Class 4 CR Class selected in CC is class 0 or 2 Table A.8 - Specific actions for classes 1 and 3

Description The network connection can be disconnected if not used by any transport connection assigned to it Retransmit expedited data which are unacknowledged or which have been stored when waiting for reassignment (if any). If a RJ TPDU has been received, enable also data TPDU transmission (if any). If an ED was received, handle according to procedures for class if not a duplicate Network connection can be disconnected if not used by any transport connection and was locally opened Start TWR timer if not already running. Disable sendinq DT TPDUs until an RJ TPDU is received (see note 3) Stop TWR timer Issue an N-RESET response if not already done See data transfer procedure for the class Start TTR timer if not already running. The sending credit is also set to zero in order not to send DT TPDUs until a RJ TPDU is received. Stop TTR timer if running or remove information that TTR timer has run out (see notes 1 and 2) Store information that TTR timer has run out (see note 1) Store request See state table appropriate to the class selected in the CC TPDU close the network connection to which the transport connection is currently assigned, apply to all transport connections assigned to this network connection the procedure for processing NDlSind and then process the TPDU reassignment. The DC TPDU contains a SRC-REF field set to zero and a DST-REF field set to the SRC-REF of the DR TPDU received. NOTES 1 This information is used by predicate P4. 2 This action is not performed if the transport entity is the responder or if neither reassignment nor resynchronization is in progress. 3 The method of disabling transmission of DT TPDUs is a local matter. In class 3 for example, it may be 6 effected by setting credit to zero. In class 1, this may be effected by setting of a boolean indicator. 74
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Table A.9 - Specific name (1) (2) (3) f4)
I I

notes for classes

1 and 3

description Any TPDU except DR and CC having an unknown destination reference CC TPDU having an unknown destination reference or a mismatched source reference CR TPDU which is not duplicated but rejected. If the CR TPDU is duplicated, ignore it Or send anv DT or ED TPDU waitina for transmission or use N-DATA ACKNOWLEDGE request if abailable and selected (cl&s 1 only) Same as for (9) and issue a T-DISCONNECT indication If the resultant state is CLOSED, the reference should be frozen except in the cases described in 6.16 An ER TPDU should be sent in the cases defined in 6.6 Receipt of a DC TPDU is a protocol error since DC cannot be used for reassignment. It is recommended to stop the TWR timer ([5]) and to consider the transport connection as released (CLOSED STATE) Receipt of one of these TPDUs in this state is a protocol error. It is recommended to stop the TWR timer ([5]), and send a DR TPDU and enter the closing state Or a DR with mismatched source reference has been received Receipt of CR in this state is only valid if the TPDU is received on a network connection to which the transport connection is not assigned. It is recommended to apply action [13]. Receipt of this TPDU in this state is possible either on the network connection to which the transport connection is currently assigned or on another network connection (for the responder only). in the former case the action is as stated in the state table. In the latter case it is recommended to apply action [13]. This happens only when the preferred class of the CR TPDU received is class 4.
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Table A.10 - State table for classes 1 and 3 (First part: connection - responder side) State Event 1-DISreq CLOSED WFTRESP NFTRESPWR WBCL-WR CL::NG BOC WBOC-WR NBCL-WR WR CLOSING BOC-WR :LOSING BOC CLOSING BOC-WR

DR CLOSED (6) PlO: (12); not PlO: CC WBOC WKK~P -WR

1 I'CONresp

rrlRSTind

W&SP -WR WFTRESP -WR WF#ESP

NBF-WR

Cl!%%G WI%BOC-WR WR

CLd"sllNG BOC-WR CLOSING BOC-WR DR PI CLOSED (`3)

1 JDlSind

WF+ESP -WR
(ZR

A'BCL-WR

WI&WBOCWR WR
W& not P9: (11) WBOC

141 CLOSING BOC-WR CL&?,, BOC; lot P9: (11)

P7: DR (Y and 7) CLOSED no%7* TCONinb; WFTRES P

P9: WFTRESP; not P9: (11)

CLOSED (6)

PI DR

151 cc

I3R

CL::ED

i
I RJ or ED

P5: DC [14] (13) TDlSind CLOSED

TDlSind DC CLOSED (6) (12) OPEN [A (12)

DC (5) TDlSind CLOSED

CLOSED (6) (12)

(51 DC CLOSED (6) 151DR CLOSING

CLOSED CLOSED CLOSED

CLOSING (12) CLOSED

I DC I First TPDU ,other than ,CR, DR, I DC, ED,

(6) (9)

OPEN [7j

CLOSING

ER or RJ TWR time-out TDTreq TDlSind CLOSED (6) CLOSED (6) TDlSind CLOSED (6) WBOCWR TEXreq WKZWR ER TDlSind CL::NG BOC CLOSED CLOSED (6)

illI
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Table A.10 (continue) - State table for classes 1 and 3 (Second part; connection initiator side) State Event TCONreq

-ii&q-F
PO: TDlSind CLOSED: not (PO aid Pl) NCONreq WFNC; not (PO and P2): WFNC; not (PO and P3): CR WFCC CR WFCC

WFNC-R

WFCC

WFCC-R

WBCL

WBCL-R

NCONconf NRSTind

-I-P2: WFNC: R; P3: CR WFCC 1) CLOSED (6) PI Pl: i8] NCONreq WFCC-R; (not P4) and P2: [8] WFCC-R; (not P4) and P3: [8] CR WFCC WBCL

CR WFCC I`4: [6] CLOSED

CR WBCL

PI;

not P4: CR [6] [8] WBCL VDlSind Pl: NCONreq WFCC-R; P.2: WFCCP3%R WFCC f`4 or P5: [l and ,3) (6) CLOSED; l[not (P4 or P5)) and Pl: [8] NCONreq WBCL-R; (not (P4 or P5)) a;;FLj !I (not (P4 or P5)) and P3: [8] CR WBCL P5: :LOSED (6;I [l and 91; not P5: WBCL-R CLOSED (6) P5: CLOSED (6) PI; (not P5) and Pl: NCONreq WBCL-R; (not P5) and P2: WBCL-R, (not P5) and P3: CR WBCL

'

`DISreq

[l] CLOSED (6)

)R

(AZ CLOSED (12) DR CLOSED

-.-j-r_

(11 PI

:C

PlO: (121; not Pl 0: DR CLC(?lNG

1) 2)

CLOSED CL::ED

TTR ime-out

TDlSind :LOSED (6L-

ill

I101 111 PI

CLOSED (6)

VI

CLOSED (6)

77

IS 13919 : 1994 ISO/IEC 8073 : 1992

Table A.10 (concluded) - State table for classes 1 and 3 (Third part: OPEN and CLOSING states) State Event NCONconf TDlSreq P8: CLOSING; not P8: DR CLOSING P6 and P4: (6) [S] [3] TDlSind CLOSED; (P6 and not P4): OPEN CLOSING-R ZLOSING-WR OPEN OPEN-R OPEN-WR CLOSING CLOSING-R DR CLOSING CLOSING-WR

RJ PI

NRSTind

P6 and P4: (6) [6] [3] CLOSED; P6 and not P4: CLOSING; not P6: [4, 61 CLOSING
Pl : NCONreq

bI~~FW~~RJ
not P6: [4 and 61 OPEN NDlSind P6 and P4: TDlSind CLOSED OPEN-R; P2:OPEN-R; P3: [2] RJ OPEN

Fl PI DR

P6 and (P5 or P4): CLOSED P6 and not (P4 or P5) and Pl: [8] NCONreq CLOSING-R; P6 and not (P4 or P5) and P2: [8] CLOSING-R; P6 and not (P4 or P5) and P3:

(6);
(P6 and not P4) and Pl: 181 NCONreq dP'EN(P6 andRiot P4) and P2: [S] OPEN-R; (P6 and not P4) and P3: [8] [2] RJ OPEN; not P6: [4] OPEN-WR RJ or ED P8: [5] [2] RJ OP_EN;

iSI;

P5: CLOSED (6); (not P5 and Pl): NCONreq CLOSING-R; (not P5) and P2: CLOSING-R; (not P5) and P3: DR CLOSING

PI DR
CLOSING; not P6: [4] CLOSING-WR RJ [5 and 21 OPEN P8: [5] DR CLOSING; not P8: [9] CLOSING (12) CLOSED (6) DR [51 CLOSING

ng;;;[yJ91
TWR time-ou, DR P8: TDlSind DC (6 p] CLOSED; not P8: TDlSind DC (6) PI CLOSED (12)

T;:So"sdEb"'
TDlSind DC [51 CLOSED (6)

CLOSED (6) [5] CLOSED (6) DC

P8: [5] DC (6) CLOSED; not P8: [3] [9] (6) CLOSED (12) P8: (8); "6;,`,";b"16"1

DC

(8)
(9)
CLOSED [Al (6)

DT, AK, or El TPDU TTR time-ou

[7l OPEN VOI TDlSind CLOSED [1] (6) O&d-R illI OPEN-R OPk?WR illI OPEN-WR TDlSind DR CLOSING 78

CLOSING

TDTreq TEXreq ER

P8: [l l] OPEN; not P8: [7] OPEN P8: [l l] OPEN; not P8: [7] OPEh TDlSind DR CLOSING

CLOSED (6)

CLOSED (6)
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A.6

State tables for class 4 over CONS

f) when a TPDU is received the network connection on which it has been received is assumed to be known; g) the variable "current-n6 is used to designate either the network connection on which a TPDU has been received or the network connection which has been chosen for a new assignment (either an existing one or a new one which is created); h) the following variables are also used: localzref: the reference (local) of the TC is chosen when sending the CR or when accepting a CR; remote-ref: the reference of remote entity is initially set to zero and initialized when processing the CC except if the CC is ignored; SRC-REF: designates the corresponding field of the received TPDU; DST-REF: designates the corresponding field of the received TPDU: src-ref, dst-ref: designates the corresponding field of the sent TPDU; count: designates the number of times a TPDU has been sent (retransmissions); i) the data transfer phase is not completely described in the state table but refers to the main text; k) a spontaneous event called "new network connection assignment" has been introduced. It may occur at any time provided Pl or P2 are true (see tabte A.1 1) and the remote ref is not zero (i.e. a CR TPDU has been received or a CC TPDU has been. received and processed);

This clause provides a more precise description of a class 4 Transport Connection. Tables A.1 1, A.12, A.13 give the predicates, notes for class 4 respectively. Table A.14 connection. is the state table for a class actions and

4 transport

The following assumptions and notations are used: a) the state of *very ~network connection is known as being open or opening (i.e. a NCONreq has been issued and the NCONconf is awaited); b) for each transport connection the transport entity maintains the set of network connections to which the transport is assigned. A network connection in this set is either in open or opening state; c) when an N-CONNECT confirmation, N-RESET indication or N-DISCONNECT indication is received this event is associated with the transportconnection if the network connection belongs to the set; d) when an N-DISCONNECT is received, the network connection becomes unexisting and is therefore withdrawn from the set. When a NCONconf is received the state of the nc becomes "open";
NOTE - This is not shown by an explicit action in the state table. Conversely adding a network connection to a set and setting its state to `opening' is shown by an explicit action.

e) when the state goes back to CLOSED or REFWAIT state, it is assumed that all timers are stopped (if running), the count is set to zero and the set becomes empty;

ml

when an N-RESET indication RESET response is issued.

is received,

an N-

Table A.1 1 - Predicates for class 4 over CONS
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Table A.12 - Specific actions for class 4 over CONS Name Description Set reference timer Count = count + 1 Count = 0 Set retransmission timer Stop retransmission timer if running Set window timer Stop window timer if running Set inactivity timer Stop inactivity timer Set initial credit for sending according to the received CR/CC TPDU Set initial credit for controlling reception according the the sent CWCC TPDU Send the CR TPDU if there is a network connection in the open state in the set Add the current network connection to the set, if not already included The current network connection is now in opening state Send the CC TPDU if a network connection in the open state is in the set Send the DR TPDU if a network connection in the open state is in the set. This DR TPDU is sent with SRC-REF = local-ref and DST-REF = remote-ref (may be zero) Send the DR TPDU if a network connection in the open state is in the set. The DR TPDU is sent with SIX-REF = 0 and DST-REF = remote-ref Send a TPDU according to data transfer procedure See state table of the class specified in the CC TPDU (refer to data transfer) See state table of the class (refer to release procedure): not 0, otherwise issue an N-DISCONNECT request Store request and exercise flow control to the user Send a DR TPDU with SRC-REF field set to zero Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to zero send a DR TPDU if the class is

PI
111 121 t31 141

PI
PI
171

PI PI
tto1

(111
[121 1131 1141 1151 tt

'51

if71

081

[191 PO1
WI

WI
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Table A.13 -Specific Name

notes for class 4 over CONS Description

51
(:,

(3) (4)

Not possible as no set of Network Connections is associated with this transport connection It is also possible to remain in the same state (Tl is still running) until - a CC TPDU is received which performs a new assignment; - a new assignment is tried (spontaneous event); - Tl runs out and the count is equal to the maximal value No new assignment was possible: if the set is empty, the transport entity waits until a new assignment is received, or can be locally performed (spontaneous event) It is also possible to perform a new assignment. (This may be done in triggering the event "new network connection assignment") Not a duplicated CR TPDU. If the CR TPDU is duplicated, ignore it Since a new network connection is now assigned, it is recommended that the appropriate TPDU be sent on this network connection (if open) in order to make the remote entity aware of this assignment. It is also possible to allow the normal retransmission procedures to cause the TPDU to be sent; however, the first TPDU available for sending should be sent on the new network connection As a local choice it is also possible to apply the following: [O). TDISind, REFWAIT Association to this transport connection is carried out regardless of the SRC-REF field. If the SRC-REF is not zero, a DC TPDU is sent back At least an AK TPDU shall be sent if the transport entity is in the initiator in order to ensure that the responder will complete its three-way handshake If association has been made, and DST-REF is zero, then the DC TPDU contains a SRCREF field set to zero If the CLOSING state has been entered, coming from WFCC state, the remote-ref is zero. The SRC-REF field of the CC TPDU is ignored (i.e. if the DR TPDU is retransmitted, it will be with DST-REF field set to zero) If the CLOSING state has been entered, coming from WFCC state, the remote-ref (which is zero) shall be set with SRC-REF in order to comply with the release procedure of the negotiated class The DR TPDU may be either repeated immediately or when Tl will run out If the set is empty, this event may be used as a criteria for triggering the event "new network connection assignment" Previously stored T-DATA or T-EXPEDITED DATA requests are ready for processing according to data transfer procedures See data transfer procedures When an N-RESET INDICATION is received, an N-RESET RESPONSE has to be issued once independent of the state automata

c

81

IS13919:1994 ISO/IEC 8073 : 1992

. State Event rCONreq REFWAll

Table A.14 - Class 4 connection/disconnection WFCC WBCL OPEN

over CONS WFTRESP AKWAIT CLOSING

CLOSED

not PO: TDlSind CLOSED; PO and Pl :

V;")

3;"

WFCC; PO and not Pl and P2: [13. 12, 1.3 and lo] NCONreq WFCC; PO and not TD!&d CLOSED fCONresp

[3, 2, 1, 10
and 141 AKWAIT

rDlSrsq CL::ED; (not P4) and P3: WBCL; (not P4) and (not P3) [4,3, 2,1 and151 CLOSING UDlSind

`7 ",;$v 1";;s
CLOSING

U`31 CLOSED CLOSING

(1)

(1)

P3: [O] REFWAIT; (not Pi) and (not P3) P2: [13 and and Pl : 12]{;g;req [12andll WBCL; (not Pl) and (not P3) (not P2): (01 and (not Pl) and ~~2&D$SAil1-" P2: [13 and 121 NCONreq WBCL; (not P3) and (not Pl) and (not P2): y& REfiAIT

P5 and Pl:

WFTRESP (4)

P5 and

Pl :

[26', "dp"E'N'l P5 and (ndt Pl) and P2:

[12ZP 141

[fc;;r;;l
OPEN; P5 and (not Pl) and (noi P2): OPEN (3); not P5: OPEN

AKWAIT; P5 and (not Pl) and P2:

[;cJ3$r;;l
AKWAIT; P5 and (not Pl) and (not P2): AKWAIT (3); not P5: AKWAIT

NRSTind TDTreq rEXreq NCONconf New

(17)

(17)

(17) (16) OPEN 1171 OPEN (6) Pl: [12 and 17) OPEN (6): (not Pl) ant P2: [13 and 121 NCONreq OPEN 82

(17) -&AKWAIT cc ADWAIT (6) Pl: [12 and 141(6) AKWAIT; (not Pl) and P2: [13 and 121 NCONreg AKWAIT

P6: [0] REFWAIT; `not P6) and P5 and Pl: [12 and 151 CLOSING (6); Inot P6) and P5 and (not Pl) and P2: [13 and 12) NCONreq CLOSING; Inot P6) and P5 and (not Pl) and (net P2): CLOSING (3); (not P6) and (no! P5): CLOSING (17)

(1)

(1)

CR WFCC (6)

WFTRESP Pl: [12] WFTRESP (6); (not Pl) and P2: [13 and 121 NCONreq WFTRESP

[ 151CLOSING
(6) Pl: [12 and 151 (6) CLOSING ; (not Pl) and P2: [13 and 121 NCONreq CLOSING

WB:?

(6)

IMWOrk
:onnectidn assignment
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Table A.14 - Class 4 connection/disconnection State REFWAIT CLOSED WFCC WBCL

over CONS (conc/udecf) OPEN WFIRESP AKWAIT CLOSING

Event btransimer

p7;;g3p

P7 and P3: I 1 REF!!AlT;
I`7 and (not

REFWAIT; P7 and (not P3): [3, 2, 1 and 151 TDlSind CLOSING (14); not P7: [l, 3

I`3): [3,2. 1 and 151 CLOSING (14); not P7: [l, 3, and 111 WBCL

P7: [6, 8,3, 2, 1 and 151 TDlSind CLOSING (14); not P7: (16) (14) OPEN

`7: [3, 2, 1 and 151 TDlSind (14)

ZLOSING; not P7: [l, 3and14]
(14)

P7: [O] REFWAIT; not P7: (1, 3and15] (14) CLOSING

AKWAIT

nactivityimer

P,a$3i 5' 1
TDlSind CLOSING (7)

bference imer
X-3

CLOSED
Ilot

P8: (211 CLOSED (5); P8: [9 and 121 TCONind WFTRESP (5)

(12,8 and 71 OPEN

WFrRESP

WI

[12 and 141 AKWAIT

(121
CLOSING (13)

X

DR REFWAIT

DR CLOSED

P9: [12, 9, 2, Pll: [19]; 4, 57 and not Pll: 112, 2, 4,3, 171 TCONconf (91 1 and 151 OPEN; CLOSING PlO: [12,4,3 2,1 and 15) TDlSind CLOSING; Pll: (181 [0] TDlSind REFWAIT b-4 REFWAIT

[12, 17,8 and 71(9) OPEN

Pll: [19] (12); not Pll: CLg:/NG (11)

ER

REFWAIT

CLOSED

[12,6, 8,4, 3, 2, 1 and

[12, 4, 3, 2,1 and TD:.`hd CLOSING

REFWAIT

PI

151TDlSind
CLOSING
DR

REFWAIT
DC

WI

CLOSED CLOSED CLOSED

WI

(8) TDlSind [0] REFWAI'I

REFWAIT REFWAIT

(`3) PI

"T"d:sp(Jl

DC (10) TDlSind CLOSED

D;Dp~l
REFWAIT

REFWAIT

WI

REFWAIT REFWAIT

PI REFWAIT [12, 8 and 71 OPEN (16) [12, 8 and 71
OPEN (16)

EA

DTIAWED

REFWAI'I

CLOSED

(12and7j OPEN (15: (16)
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A.7

State tables for class 4 over CLNS

SRC-REF: designates received TPDU; DST-REF: designates received TPDU;

the corresoonding the corresponding

field of the field of the fields

This clause provides a more precise description of a class 4 transport connection when operating over CLNS. Tables A.15, A.16, A.17 give the predicates, notes for class 4 respectively. Table A.16 is the state connection when operating The following assumption table for a class over CLNS. and notations actions and

src-ref, dst-ref: designates of the sent TPDU;

the corresponding

4 transport

count: designates the number been sent (retransmissions);

of times a TPDU has

are used

b) the data transfer phase is not completely in the state table but refers to the main text; c) it is assumed that the network service available: The operations resulting from signalled network service are a local matter.

described

4 local-ref: the reference (local) of the TC is chosen
when sending the CR or when accepting a CR; remote-ref: the reference of the remote entity is initially set to zero and initialized when processing the CC except if the CC is ignored:

is continuously

inaccessibility

of the

Table A.15 - Predicates for class 4 over CLNS

T-CONNECT

re uest is acce table,

~~

Table A.16 -Specific Name IO) [l) 12: [3: [4. 15, (61 (7 18 19:

actions for class 4 over CLNS

[ 1
,;:I [16` [17:

[

:

[ZY] [221 [23]

Description Set reference timer Count = count + 1 Count = 0 Set retransmission timer Stop retransmission timer if running Set window timer Stop window timer if running Set inactivity timer Stop inactivity timer if running Set initial credit for sending according to the received CR/CC TPDU Set initial credit for controlling reception according to the sent CWCC TPDU Send the DR TPDU. This DR TPDU is sent with src-ref = local-ref and dst-ref = remote-ref (may be zero) Send the DR TPDU. The DR TPDU is sent with src-ref = 0 and dst-ref = remote-ref Send a TPDU according to data transfer procedure Store request and exercise flow control to the user Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to zero Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to zero Send a DR TPDU with src-ref = local-ref and dst-ref = SRC-REF in CC TPDU
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Table A.17 - Specific Name (5)

notes for class 4 over CLNS Description

0 (i) (9) (10) (11)

16)

Not a duplicated CR TPDU. If the CR TPDU is duplicated, ignore it. As a local choice it is also possible to apply the following [0], TDISind, REFWAIT. Association to this Transport connection is done regardless of the SRC-REF field. If SRC-REF is not zero, a DC TPDU is set back. At least an AK TPDU shall be sent if the transport entity is the initiator in order to ensure that the responder will complete its three-way handshake, If association has been made, and DST-REF is zero, then the DC tpDU contains a src-ref field set to zero. If the CLOSING state has been entered, cominq from WFCC state, the remote-ref is zero. The SAC-REF field of the CC TPDU is ignored (i.e. if the DR TPDU is retransmitted, it will be with the dst-ref field set to zero). The DR TPDU may be either repeated immediately or when Tl will run out. Previously stored T-DATA or T-EXPEDITED-DATA requests are ready _ for processinq according to data transfer procedures. 1 See data transfer procedures.
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Table A.18 -Class STATE EVENT REFWAIT CLOSED

4 connection/disconnection WBCL OPEN

over CLNS (1 of 2) WFTRESP --AKWAIT CLOSING

WFCC

TCONreq

not PO: TQlSind CLOSED: loA 1O] CR wzc

TCONresp .I___ -I ._.I TDlSleq -P3: WBCL; not P3:

32,1,101 :C

4KWAIT

:W4,32,1,
151 CLOSING

:LOSED

1`31

%v2p' (
CLOSING

gJ~&`cs1
TDTreq TEXreq Retrans!im&

(16)
P7 and P3: kSind REFWAIT; P7 and (not P3): I3,2,1 ,I 51 TDlSind CLOSING; not P7: k;%ER 27 and P3:

PO1
AKWAIT P7: [3.2.1.15] TDlSind CLOSING; not P7:
37:

OPEN

`01

3EFWAIT; 37 and :not P3): `3,2,1,15] ZLOSING; lot P7: :1,3l,CR J\IBCL;

$321 151 Tlkkkd ' CLOSING; not P7: (1'3) OPEN;

91

[ 1,3l,CC
AKWAIT;

?EFWAIT 101 P7: `1,3,15] ti~0SlNG

I

I

GJ---+Timer

,

I

t

WI

V3.71 OPEN

JVFTRESP

cc
AKWAIT

CLOSING
(13)

CLOSED; P8: 11,w TCONind WFTRESP (5):

1
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Table A.16 - Class 4 connection/disconnection STATE EVENT cc REFWAIT CLOSED WFCC WBCL

over CLNS (2 of 2) WFTAESP AKWAIT CLOSING

OPEN

DR REFWAIT

::OSED

pg"; 4 5 7 171 T&i&;f %EN; not P9:
yg&y31

[17,6,7]

P9: (11)

CLOSING

ER

, REFWAIT

CLOSED

CLOSING; FJ,Sind %FWAIT REFWAIT

[6,6,4,32,l,l5]

TDlSind CLOSING DC (lo) !%Sind REFWAIT DC (lo) TDlSind CLOSED

DR

PI

REFWAIT

CLOSED

P21

/:j) TDlSind REFWAIT
I

(8) 101 REFWAIT

[432,1,15] TDlSind CLOSING DC (IO) bind REFWAIT

[O] REFWAIT

PI

REFWAIT

DC
I

REFWAIT
I

CLOSED
I

PI
:8,71 3PEN (16)
:`3,71 (71

EA DTIAWED
I

1 RiFWAlT 1 CLOSED 1
REFWAIT
I

REFWAIT CLOSING
(13)

CLOSED
I I

CLOSING
(13)

3PEN (16) I

OPEN
(15) (16)

87

IS13919:1994 ISO/IEC 8073

: 1992

\

Annex B
(normative)

Network connection management subprotocol

B.l

Introduction
of this annex are to

The objectives

a) Provide for more flexibility in the use of the network connections established between two cooperating transport entities, thus enlarging the field of application of the transport protocol as presently defined in the main body of this International Standard. In particular it allows for an optimization of the use of the network connections by allowing both transport entities at each end of a network connection to assign and reassign transport connections to a network connection; b) Allow more information to be sent explaining why a network connec!ion is released in order to be able to optimize recovery; The protocol described connection management in this annex is called the network subprotocol (NCMS).

In order to control the number of shared network connections that peer entities are willing to use simultaneously (one or more), a mechanism is provided to resolve collisions when simultaneous network connection establishments occur, especially in the case of recovery after network failure.

8.3

Definitions
of this annex, the following definitions

For the purposes apply.

NOTE - The definitions contained abbreviations defined in clause 8.4.

in this clause

make

use of

The procedures defined in this annex are optional extensions to the main body o! this Interna!icnal Standard.

8.3.1 owner (of a network connection): The transport entity that issued the N-CONNECT request leading to the creation of the network connection if the NCM TPDU is not used or the transport entity (possibly both) which is designated to have the right of performing assignment in accordance with the NC-RIGHT field of the NCM TPDU when the NCM TPDU is used (see 8.6.2.2).
NOTE - This definition extends the definition network connection given in 3.2.28. of the owner of the

8.2

Scope

The procedures specified in this annex are an extension of the basic procedure defined in the main body of this Internaiional Standard and therefore do not prevent communica!ion between transport entities conforming to this international Standard (ISCVIEC 8073) with this annex and those'conforming to this International Standard without this annex. The basic network connection management that is specified in the main body of this International Standard allows for assignment or reassignment of transport connections on an existing network connection by its owner, who is currently restricted to be the transport entity that initiated this network connection, This addendum describes the procedures necessary to extend this basic management to permit the peer transport entity (i.e. the acceptor of a network connectron) to become also the owner of the network connection and consequently to be able to assign or reassign transport connections to it. When performing multiplexing of transport connection this feature allows a network connection to be fully shared, thus increasing the scope of the multiplexing classes of the transport protocol (i.e. classes 2, 3 and 4).

8.3.2 network connection reference (or ncreference): An identifier which is associated with a network connection and used to resolve collisions when network connections are reopened.

8.4
B-4.1

Symbols
Types

and abbreviations

of transport-protocol-data-units Network connection TPDU management management TPDU

NCM TPDU DIAG TPDU NCMC .

Diagnostic

.

TPDUNetwork connection confirmation TPDU

The following TPDU is used by this annex and is defined by ISO/IEC 11570, Transport protocol identification mechanism: UN TPDU Use of network connection TPDU
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B.4.2

TPDU fields Network Network Network connection connection right (field) (field) preference collision recovery (field) reference type (field) (field)

SA RA AFI

Sender has assignment Receiver has assignment

right right Identifier (of the

NC-REF NC-TYPE NC-RIGHT LI NC-PREF NC-COL NC-REC

Authority and Format NSAP address) Initial Domain address) Domain address) specific Identifier

IDI

(of the

NSAP

Length indicator Network Network Network

connection connection connection

DSP

part

(of

the

NSAP

indicator indicator

B.5

Overview

of the protocol

The following fields of the UN TPDU are used by this annex and are defined by ISO/IEC 11570: SHARE PRT-ID 8.4.3 Timers Time to connection try to reopen a network using a given NC-REF a given NC-REF as Sharing Protocol option (field) identifier (field)

NCMS allows for: a) identification of the protocol given network connection: to be used on top of a

TTR-NC

NOTE -The use of NSAP addressesas it is defined is ISO/IEC 7498-3 provides greater flexibility in distinguishing between OSI and non-OS1 users of the network service. If however the use of NSAPs incurs unacceptable penalties, for example where each NSAP is charged for by the network.provider, then the protocol identification mechanism (see ISOllEC 11570) is available. b) Explicit designation of the transport entity (or entities) which has the right to assign transport connec!ion(s) to a specific network connection and is therefore considered as the (co-)owner of the network connection; c) Resolution of connection when a network connection recovered after failure. establishment collisions is first established or

TPD-NC

Time to consider pending Time to consider frozen

TFR-NC

a given

NC-REF

as

8.4.4 NCMS

Miscellaneous Network subprotocol connection management

NCMS assumes lSO/lEC 8348.

the use of the network

service

defined

in

NSAP AA

Network-service-access-point Assignment right to all

When operating NCMS the transport entities use only the network service primitives listed in table a.1 (the other network service primitives are used as defined in 5.2).
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Table

B.l - Network Primitives

Service

Primitives

Used for NCMS Operation Parameters AIBIC A A B A A A C C A

N-CONNECT

request indication response confirm

Called address Calling address NS user-data 00s parameter set Responding address Receipt confirmation selection NS user-data Originator Reason

N-DISCONNECT

request indication

A: B: C:

This parameter is used in accordance with the procedures specified in the main body of this International Standard. When operating NCMS this parameter is used in request and indication and in response and confirmation if the NCMC TPDU is used.

This parameter

may be optionally

used when operating

NCMS.

B.6
B.6.1

Elements of procedure
TPDU transfer (TPDUs) defined for this

a) The sending transport entity shall use the procedure described below together with the procedure defined in the main body of this International Standard; b) The receiving transport entity shall

The transport-protocol-data-units annex are listed in 8.4.1.

1) either ignore the NCM TPDU and operate the procedure described in the main body of this International Standard; 2) or recognize and process the NCM TPDU and therefore operate the procedure described below together with those defined is the main body of this International Standard. When a transport entity has processed an NCM TPDU received from a given NSAP [see 8.6.2.1 b)2)] it shall process further NCM TPDUs received from the same NSAP. B.6.2.2 Assignment right

The transport entities shall transmit and receive the UN (see ISO/IEC 11570) and NCM TPDU in the NS-user data parameter of the N-CONNECT request and indication primitive only. The sending a) Either parameter transport entity shall: data

not transmit any TPDU in the NS-user of the N-CONNECT request primitive;

followed

b) Or transmit the UN TPDU (see ISO/IEC 11570) by the NCM TPDU in the NS-user data parameter of the N-CONNECT request primitive.

When used the DIAG TPDU is transmitted in the NS-user data parameter of N-DISCONNECT primitive. When used the NCMC TPDU is transmitted in the NS-user data parameter of N-CONNECT response and confirmation primitive. B.6.2 8.6.2.1 Network connection management

When an N-CONNECT request primitive is issued by a transport entity to request the opening of a new network connection, the transport entity may choose whether or not to include the NCM TPDU in the NS-user data parameter of the primitive. The recipient may choose not to process the NCM TPDU and to operate the procedures defined in the main body of this International Standard instead. The owner(s) may use the network connection for assigning or reassigning transport connections with the following restrictions: a) a transport entity which is the owner of the network connection shall not assign a transport connection with a preferred class 0 or 1 if its peer is also the owner of the network connection (see note 2); 6

General described in B.6.1 b) is used

When the procedure
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b) a transport entity which is the owner of the network connection can assign a transport connection with an alternative class 0 or 1, but shall not, when receiving a CR TPDU proposing 0 or 1 as an alternative class, select one of these classes (see note 3). A transport entity network connection shall be designated the "owner" according to the table 8.2. of assignment rights of a

NOTE - The transport protocol defined in the main body of this International Standard makes use of the definition of owner of a network connection for defining the entity which can perform assignment and reassignment. 8.6.2.3 Network management connection reference (nc-reference)

Table 8.2 - Determination Entity

When a transport entity elects to use the NCM TPDU it shall keep track of the nc-references used in the NCM TPDUs sent or received in the NS-user data parameter of the NCONNECT request or indication primitives. An nc-reference is associated with

,
Event No NCM sent NCM sent but not processed Right = SA or AA NCM sent but not processed Right = RA

a) the pair of NSAPs addresses involv&d in the network connection on which the NCM TPDU has been transferred: b) the source of the allocation: been remotely or locally allocated. the nc-reference has

NCM sent and processed Right = SA NCM sent and processed Right = RA NCM sent and processed Right = AA Key Y: N: owner not owner

--i-i-T

rl
Y

The nc-reference is exchanged as the NC-REF parameter of the NCM TPDU. The NC-TYPE parameter of the NCM TPDU indicates the source of allocation: 1') NC-TYPE set reference allocated to NEW indicates a new ncby the sender of the NCM TPDU,

Y

2) NC-TYPE set to MY indicates a recovery using an nc-reference previously allocated by the sender of the NCM TPDU. 3) NC-TYPE set to YOURS indicates a recovery using an nc-reference previously allocated by the receiver of the NCM TPDU; NOTE - Use of the NC-TYPE MY permits the explicit distinction between the two cases where the NC initiator either has or has not received the N-CONNECT confirm. c) the state of the nc-reference which can be

NOTES 1 The use of a network connection by a called transport entity to initiate new transport connections should only be made when the called transport entity is adequately assured of the true identity of the calling transport entity (i.e. there is trust in the calling NSAP identification provided by the Network Layer) or the data to be transferred is not sensitive. 2 This gives the guarantee that transport connections of classes 0 or 1 cannot be opened simultaneously at both ends of a network connectron. 3 This allows a transport entity which has sent the NCM TPDU to still propose classes 0 cir 1 as an alternative class. if the peer transport entity has not processed the NCM TPDU it may still select class 0 or class 1. 4 Use of NC-RIGHT with the NCM TPDU allows explicit control of assignment rights whilst also permitting both entities to be able to recover a failed network connection. This is not possible when the NCM is used. Provided that the restriction stated in 8.6.2.2 a) and 8.6.2.2 b) are respected, both transport entities at each end of the network connection shall follow the procedures defined in the main body of this International Standard, except that the owner of the network connection is defined as in 8.6.2.2.

There is one network connection 1) OPEN: associated with the nc-reference and for which an NCONNECT confirm has been received or an NCONNECT response sent, and no subsequent NDISCONNECT primitive exchanged, 2) OPENING: There is one network connection for which an N-CONNECT confirm is awaited and the nc-reference has never been previously in the OPEN state, 3) RECOVER: There is one network connection associated with the nc-reference for which an NCONNECT confirm is awaited and the nc-reference has previously been in the OPEN state, 4) PENDING: There is no network associated with the nc-reference: d) the assignment network connection can be connection

right allocated for the use of the associated with the nc-reference. It

1) my-side: The local transport owner of the network connection, 91

entity *

is the only
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2)

remote-side: The remote transport only owner of the network connection,

entity

is the

a) either the three following

conditions

are met:

3) both-sides: Both the local and the remote transport entities are the owners of the network connection; NOTE - Due to the collision and recovery mechanisms, it is possible that different network connections - initiated either by the local or the remote transport entity - be consecutively associated to the same nc-reference. The assignment rights are attached with the nc-reference 2nd remain unchanged independent of whichever transport entity is the initiator of the network connection currently used. e) The preference to be used in the collision resolution mechanism (see B.6.2.5). This value is equal to the value of the field of the last NCM TPDU sent and is onlv significant when an N-CONNECT confirm is awaited (i.e. the nc-reference is either in the OPENING or in the RECOVERY state).
an nc-reference which has been locally allocated is no longer needed, the nc-reference shall not be reused before a TFR-NC period of time. No information is associated with this frozen reference other than the TRF-NC timer and will be considered unknown if received in an NCM TPDU. When NOTE - In order to prevent that, in collision cases, two ncreferences have the same value, it is required to allocate values at random, for example based on the time of their allocation.

1) the reference number received in the NC-REF parameter is the same as the one stored; and 2) the pair of NSAPs addresses in the N-CONNECT indication in which the NCM TPDU was received is the same as those stored with the reference; and 3) the parameter received in the NCM TPDU indicates the same source of allocation as that stored with the nc-reference, as indicated in table 8.3; Table 8.3 - Matching source of nc-reference allocation

~,

Key

S = Same allocation source D = Different allocation source by the transport above and trse

b) or there is no nc-reference known entity corresponding to 6.6.2.5 a)l) following three conditions hold:
1) the NC-TYPE

parameter

has the value NEW;

B.6.2.4

Timers management procedure makes use

2) there is an nc-reference, locally allocated, joining the same pair of NSAPs addresses, in OPENING state and having the assignment right defined as foflows:

The network connection of the following timers:

- assignment right is "my-side" and the RIGHT field of the received NCM TPDU holds the value RA (receiver has assignment right); - or assignment right is "remote-sides" and the RIGHT field of the received NCM TPDU holds the value SA (sender has assignment right);
or assignment right is "both-sides" and the

a) the TTR-NC timer defines the period of time that shall not be exceeded when reopening a network connection associated with a given nc-reference after the receipt of an N-DISCONNECT indication in OPENING or RECOVERY state, TTR NC shall be less than TPD-NC by at least the sum of the maximum disconnection and maximum connection propagation delays of the network service; b) the TPD-NC timer defines the minimum time a transport entity shall maintain an nc-reference in the PENDING state. A value of 2 min is used for TPD-NC; c) the TFR-NC timer defines the minimum time that shall elapse before an entity may reuse a locally allocated nc-reference. A value of 2 min is used for TFR-NC. Association B-6.2.6 known nc-reference of a received NCM TPDU with a

RIGHT field of the received NCM TPDU holds the value AA (assignment right to all); 3) acceptance of both network connections would result in the establishment of more connections than the transport entity is prepared to support. An NCM TPDU which is not associated but carries a value different from NEW in the TYPE parameter has to be considered an error. B-6.2.6 8.6.2.6.1 Collision Collision cases when: with a known nc-

A collision is detected

When an NCM TPDU is received according to B.6.1 c) and 8.6.2 and processed (a transport entity may always elect to process or ignore an NCM TPDU), the NCM TPDU is associated with an existing nc-reference if one of the following holds:

a) an NCM TPDU is associated reference (see 8.6.2.5) and;

peading b) there is an N-CONNECT confirm network connection used for the nc-reference.

for the
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NOTE - In other words a collision is an association with an ncreference either in OPENING or RECOVERY state. 8.6.2.6.2 8.6.2.6.2.1 Collision resolution mechanism

TPDU shall, if accepting the incoming network connection, transmit an NCMC TPDU in the NS-user data parameter of the N-CONNECT response. NOTES 1 The NCMC TPDU is sent only if a) The incoming network connection
is accepted: and

Collision winner

When a collision occurs, one of the two network connections (i.e. the one which is currently used for the ncreference and the one carrying the NCM TPDU which is associated with the nc-reference) has to be disconnected. In general the state of the nc-reference determines network connection shall be disconnected. However, in the following two cases: which

b) The received and

NCM TPDU has the TYPE field set to NEW;

c) The received NCM TPDU has the RIGHT field set to RA.
2 This mechanism avoids possible useless freezing of resources (network connection) when the peer-entity ignores an NCM TPDU which gives exclusive assignment.

a) the NCM has been associated with an nc-reference in RECOVERY state according to 8.6.2.5 a) and the TYPE parameter has a value different from NEW,
NOTE -In b) or the B.6.2.5b). this case both ends are in RECOVERY state. to

If an N-CONNECT confirmation is received after having an NCM TPDU with RIGHT set to RA, which does not carry an NCMC TPDU, the initiator shall disconnect the network connection.
NOTE -The absence of NCMC TPDU indicates did not process the NCM TPDU. that the peer-entity

NCM

has

been

associated

according

NOTE - In this case both ends are in OPENING

state.

6.7

Protocol operation
Receipt of an N-CONNECT indication

The following procedure shall be used to determine if the local transport entity is the collision winner or the collision loser. The local entity is the winner if a) the state of the nc-reference is OPENING and the local allocated nc-reference has a lower value (ncreference to be treated as a 1 B-bit integer) than the ncreference of the received NCM TPDU. In the case when both references are equal, both network connections are disconnected, i.e. refused, and both transport entities choose another nc-reference and try (eventually) again; b) the state of the nc-reference is RECOVERY and the preference attached to nc-reference is higher than the one contained in the NC-PREF field of the received NCM TPDU: c) the state of the nc-reference is RECOVERY and the preference attached to nc-reference is equal to the one contained in the NC-PREF field of the received NCM TPDU and either: 1) the source of allocation of the nc-reference is local and the value of the NC-REC field of the first sent NCM TPDU (i.e. which had NC-TYPE = NEW) was "please do not recover", or 2) the source of allocation of the nc-reference is remote and the value of the NC-REC field of the first sent NCM TPDU (i.e. which had NC-TYPE = NEW) is "please recover". 8.6.3 NCM confirmation

6.7.1

The recipient of an N-CONNECT indication which either does not contain an NCM TPDU or contains an NCM TPDU which it chooses to ignore shall follow the procedures described in the main body of this International Standard. If the NCM TPDU is lo be processed then the transport entity shall apply the procedure for association of NCM TPDU to a known nc-reference (see 8.6.2.5). If the NCM TPDU is associated then the transport entity shall apply either the procedure describe in B.7.3a) or B.7.3b) or 8.7.4.2 b) or 8.7.4.3 c) or 8.7.4.2 or B.7.5 depending upon the state of the nc-reference. Otherwise the procedure in 8.7.2 applies. 6.7.2 Passive NCM TPDU network connection establishment with

The transport entity may either decide to refuse the incoming network connection (i.e. issue an NDISCONNECT request) or accept the network connection. If the transport entity connection it shall elects to accept the network

a) issue an N-CONNECT response; if the RIGHT field of the received NCM TPDU contains the value RA the NCMC TPDU shall be transmitted in the NS-user data parameter of the N-CONNECT response; b)
C)

note the nc-reference the

and the pair of NSAPs; has been remotely

When an NCM TPDU has been sent with RIGHT set to RA the transport entity which receives and processes the NCM

note that allocated;

nc-reference

I
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d) note the assignment rights as my-side if RA has been received in the RIGHT field of the NCM TPDU, as remote-side if SA has been received or both-sides if AA has bee received; e) put the nc-reference into the OPEN state and use it for assignment or reassignment if it is (one of) the owner(s). 8.7.3 Active NCM TPDU network connection establishment with

disconnected and the incoming network connection is accepted (i.e. an N-CONNECT response is issued). If the received NCM TPDU contains the value RA in its RIGHT field the NCMC TPDU shall be transmitted in the NS-user data parameter of the NCONNECT response. The nc-reference which has been locally allocated is frozen for a TFR-NC period of time (and then released) and the transport entity keeps track of the nc-reference contained in the NCREF parameter of the incoming NCM TPDU as remotely allocated and in OPEN state. The network connection is considered as open and ready tor use as described in the main body of this International Standard, according to the assignment rights. Any transport connections assigned to disconnected connection shall be reassigned: the

The transport entity, which elects to use the NCMS procedure when opening a network connection shall send an N-CONNECT request with the UN TPDU (see ISO/IEC 11570) and NCM TPDU contained in the NS-user data parameter. The NCM TPDU parameters are set as follows: NC-REF contains the selected reference which shall neither be used for any other network connection between the same pair of NSAPs nor frozen; NC-TYPE NC-RIGHT is set to NEW; is set to SA, RA, or AA; to in

b) if an NCM TPDU is received with a TYPE parameter different from NEW and is associated, the transport entity shall 1) issue an N-DISCONNECT network connection for which confirm is awaited; request for the the N-CONNECT

2) respond to the incoming N-CONNECT by an N-CONNECT response;

indication

NC-PREF is set to low, medium or high according the preference of the initiator to keep this connection case of collision.

3) place the nc-reference in the OPEN state and consider the network connection as ready for assignment or reassignment according to the assignment rights; c) if an N-DISCONNECT indication is received, the transport entity may decide either to give up or try to reopen a network connection by issuing an NCONNECT request containing an NCM TPDU (see 8.6.1.2 and 8.6.2) which is a copy of the previously sent NCM TPDU, except that the NC-PREF parameter may be different. The decision whether a new network connection has to be opened or not is a local matter subject to the following constraints: 1) when the first N-DISCONNECT indication is received, the entity shall start its TTR-NC timer and stop it when receiving the corresponding NCONNECT confirm or N-CONNECT indication carrying an NCM TPDU which is associated and processed as described above. When the timer runs out the transport entity shall not try to open a network connection again if a new N-DISCONNECT indication is received: 2) if the network connection is intended to be used for transport connections allowing recovery, the network connection has to be reopened in accordance with the agreed upon quality of service of the supported transport connection(s). When recovery is not performed or has stopped (i.e. a new N-DISCONNECT is received and TTR-NC has run out) the nc-reference of the network connection is olaced in a PENDING state for a TPD-NC oeriod of iime. During this period the transport entity may receive an incoming NCM TPDU having this ncreference (see 8.7.4.3).

NOTE - The selection of this value can be based on the knowledge of the correspondence between the expected QOS, the cost when reverse charging is used and other optimization considerations. The initiator shall store the nc-reference together with the pair of NSAPs to be joined by the network connection being established, the value of the NC-PREF parameter sent, the ownership of the network connection and the source of the nc-reference (locally allocated in this case). The state of the nc-reference shall be set to OPENING.

The initiator shall wait for an N-CONNECT confirm to complete the establishment. If the assignment rights are "remote side" (i.e. an NCM TPDU with the RIGHT parameter having the value RA was sent) the received NCONNECT confirm shall contain an NCMC TPDU in its user data parameter otherwise the transport entity shall disconnect the network connection. If one of the following cases occurs, the initiator shall perform the action specified: a) if an NCM TPDU is received and associated according to B.6.2.5b) (TYPE = NEW) the transport entity shall apply one of the following: 1) if the local transport entity is the winner (see 8.6.2.6.2) the incoming network connection is disconnected (i.e. an N-DISCONNECT request is sent in response to the incoming N-CONNECT indication) and the nc-reference remains in the OPENING state; 2) if the local entity network connection is the loser (see B.6.2.6.2) the which was local opened is
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B.7.4 B-7.4.1

Network

connection

recovery indication

Receipt

of an N-DISCONNECT

CONNECT response), the nc-reference is placed in the OPEN state and is ready for use according to the assiqnmer,t riqhts. The network connection for which an -N-CONNECT confirm was awaited is disconnected by issuing an N-DISCONNECT request. 8.7.4.3 Passive recovery procedure

When a network connection which was established using NCMS is disconnected (i.e. an N-DISCONNECT is received) the transport entity shall either a) elect not to reopen the network connection, place the nc-reference in the PENDING state for a TPD-NC period of time, and apply the procedure described in 6.7.4.3; or b) attempt to reopen the network connection following the procedure described in 8.7.4.2. Alternative b) is subject described in B.7.3c). to the same constraints by

If an N-CONNECT indication is received which carries an NCM TPDU. which is associated to the nc-reference. the transport eniity shall send an N-CONNECT response (with an NCMC TPDU in the NS-user data parameter if the received NCM TPDU is of type NEW and has the right field set to the value RA) and put the nc-reference into the OPEN state and consider it as ready for assignment according to the assignment rights. If the TPD-NC timer expires and if the nc-reference was remotely allocated, then the transport entity does not keep track of it any longer; if the nc-reference was locally allocated, then the transport entity shall not reuse ?he reference until a TFR-NC period of time has elapsed. 8.7.5 Remotely initiated recovery is

as

In all cases the transport entity shall apply the procedure corresponding to the receipt of an N-DISCONNECT indication to all transport connections assigned to the network connection. 8.7.4.2 Active recovery procedure

The transport entity shall open a network connection by outtina the nc-reference into the RECOVERY state and sending an NCM TPDU in the NS-user data parameter of the N-CONNECT request according to B.6.1~) and 8.6.2 with the following parameters: a) NC-FIEF is set to the value of the associated with the network connection; nc-reference

When a transport entity receives an NCM TPDU which associated with an nc-reference in OPEN state it shall

a) accept the incoming network connection and issue an N-CONNECT response; if the received NCM TPDU is of type NEW and has the RIGHT field set to RA, the NCMC TPDU shall be transmitted in the NS-user data parameter of the N-CONNECT response; b) issue an N-DISCONNECT request for the network connection which was associated with the ncreference: c) apply to all transport connections assigned to this network connection the procedure defined in the main body of this International Standard for processing an NDISCONNECT indication. 8.7.6 Optimization principles indicator

b) NC-TYPE is set to MY if the nc-reference was locally allocated, to YOURS if the nc-reference was remotely allocated; c) NC-PREF is set to the desired value (see 8.7.3); may take any value:
is not significant in an

d) NC-RIGHT

NOTE - NC-RIGHT perfoning recovery e) NC-REC The transport

NCM TPDU B-7.6.1 Use of the NC-REC

is set to the desired value.

entity shall then apply one of the following: is received apply 8.7.4.1;

Although the recovery protocol is symmetrical, it should be noted that a transport entity is always allowed not to initiate recovery by putting the nc-reference into the PENDING state. NOTE - Not initiating
recovery is equivalent to having a value of

a) if an N-DISCONNECT
b)

if an NCM TPDU with type NEW is received and associated the incoming network connection is rejected; from NEW is received according to 8.6.2.6.2

zero for the lTR-NC timer.

c) if an NCM with type different the collision winner is determined and:
1)

In order to avoid unnecessary recovery being performed or recovery being delayed the'NC-REC field of the NCM TPDU should be set as follows: a) 0 (please.do not recover): indicates that the sender does not rely on recovery being performed by the receiver. and intends to recover even if not required for its own need;

if the transport entity is the winner network connection is rejected, or

the incoming

2) if the transport entity is the loser the incoming network connection is accepted (i.e. send an N-
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b) 1 (please recover): indicates that the sender expects a recovery to be done by the receiver, and does not intend to recover if it does not need it When the nc-reference is in the OPEN state, the NC-REC field of the associated NCM TPDU gives both entities a view of the recovery intention of the partner. When a transport entity has to initiate recovery, i.e. an NDISCONNECT indication has been received in OPENING or RECOVERY state and TTR-NC has not run out it is recommended that a) if the entity has received an NCM TPDU with the NCREC field set to "please recover", it should try to recover even when this is not necessary for its own assignment needs; b) if the entity has received an NCM TPDU with the NCREC field set to "please don't recover", it should not initiate recovery if this is not required for its own assignment needs; c) if the entity has sent an NCM TPDU with the NCREC field set to "please don't recover", it should initiate recovery even if not required for its own assignment needs; d) if the entity has sent an NCM TPDU with the NCREC field set to "tolease recover". it should not initiate recovery if not required for its own assignment needs. NOTE - As a local choice, it is possible to implement a symmetrical recovery mechanism by setting the NC-REC field to the value `please recover' and initiating recovery even though not required for the local assignment needs. 8.7.6.2

If the remote transport entity has assignment rights the ncreference shall be placed in the PENDING state after the network connection has been released. If the remote transport entity does not have assignment rights the nc-reference may, as a matter of local choice: a) be put in the PENDING b) c) if locally allocated if remotely state; or or

be frozen;

allocated

be made unknown.

Structure
B.8.1 Validity

and encoding

of TPDUs

Table 8.4 specifies the TPDU valid for this annex. Table 8.4 - TPDU codes

NCM, network connection

management

8.8.2

Structure
is defined in 13.2.

The structure

B-8.3 Network connection management (NCM) TPDU Use of NS-user DISCONNECT primitive data parameter in N8.8.3.1
1

Structure
2 3 4 5 NC-TYPE NC-PREF 6 NC-COL NC-REC NC-RIGHT

The reason code in the N-DISCONNECT primitive does not adequately specify enough information to completely optimize the connection recovery mechanisms since the values defined in the network service (ISOXC 8348) do not distinguish between the cases where recovery is desirable immediately or not and do not provide adequate diagnostic information. Thus the NS-user data parameter of the NDISCONNECT request may be used and may contain a DIAG TPDU. When a network connection is no longer needed, it is recommended that only the owner(s) may disconnect it, and put a DIAG TPDU with code 1 into the NE&user data parameter of the N-DISCONNECT request primitive. 8.7.7 Releasing

L' L

NCM 0000 0010

I
NC-REF I

8.8.3.2

LI

See 13.2.1. B.8.3.3 Fixed part

The fixed part shall contain

a network connection
a) NCM NC-REF NC-TYPE

: NCM TPDU code: 000 0010; : the nc-reference; : indicates
the type of the ncreference which is sent. NCTYPE consists of bits 8 and 7 of

Either entity may release a network connection at any time by issuing an N-DISCONNECT request. It is recommended to use the DIAG TPDU in order to optimize this procedure as described in 8.7.6.2.

b) c)
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octet 5 and may have the value 00 (NEW), 01 (MY) or 10 (YOURS), Value 17 is reserved: d) NC-PREF : indicates the preference the initiator has to keep the network connection in case of collision. NC-REF is bits 6-1 of octet 5: 000000 000001 000011 e) NC-COL

8.8.4.3

Fixed part

The fixed part shall contain a) DIAG: DIAG TPDU code 0000 0011;

: highest preference, : medium, : lowest preference;

b) CODE: indicates the reason for disconnecting the network connection. The following values shall be used: 0 1Collision detection Network connection resolution no longer needed (do not try to recover cannot be accepted

indicates the collision algorithm to be used. NC-COL is bit 8 of octet 6. Only one value is defined (0): resolution of collision when N-CONNECT indication is received: the indicates optimization option. bit 7 of octet 6: 0 1 recovery NC-REC is

2 -Unrecognized NC-REF with this NC-REF) 3 Network connection (temporary congestion)

4 - A new network connection cannot be accepied again (long-term congestion or shutdown in progress) 8.8.4.4 Variable part part. connection management confirm

f)

NC-REC

: please do not recover, : please recover;

There is no variable 8.8.5 Network (NCMC) TPDU 6.851 1 LI Structure

g)

NC-RIGHT

: indicates the kind of right of use
given by the entity to its peer. NC-RIGHT is bits 6-l of octet 6: 000001 000010 000011

: SA, : RA, : AA.
I

2
NCMC 0000 0100

8.8.3.4

Variable

part 8.8.5.2 LI part. See 13.2.1. (DIAG) TPDU B.8.5.3 Fixed part shall contain the

There is no variable 8.8.4 Diagnostic

This TPDU is only transferred in the NS-user data parameter of an N-DISCONNECT. It provides diagnostic information. Sending and/or processing this TPDU is optional. B-8.4.1 1 LI Structure 2 DIAG 00000011 3 CODE

The fixed part 0000 0100.

NCMC TPDU code:

8.8.5.4

Variable

part part.

There is no variable

B.9

Conformance
a network connection a transport

8.8.4.2

LI

B.9.1 When initiating entity shall either

See 13.2.1.

a) not use the NS-user data parameter of N-CONNECT request primitive and operate using the protocol601 the main body of this International Standard on this network connection; or
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b) include in the NS-user data parameter of the NCONNECT request a UN TPDU (see lSO/IEC 11570) with the PRT-ID field set to the value 01 followed by an NCM TPDU and operate the NCMS procedure together with those specified in the main body of this International Standard. 8.9.2 When processing transport entity shall either a N-CONNECT indication, a

PRT-ID field set to the value and NCM TPDUs are present;

01 (see ISO/IEC or

11570)]

c) operate using the protocol of the main body of this International Standard but ignore the NCM TPDU if the UN [with the PRT-ID field set to the value 01 (see ISO/IEC 11570)] and NCM TPDUs are present.

5.10

State Table

a) operate using the protocol of the main body of this International Standard if no user data is present or if it is not claimed that the implementation supports the NCMS procedure; or b) operate using the protocol of the main body of this International Standard together with the network connection management procedure if the UN [with the

The following state tables define the states of a network connection reference as maintained by a single transport entity obeying the procedure of this annex. Due to failures and recovceries of network connections this reference may over a period of time be associated with many network When an NCM TPDU is connections, one at a time. received the association procedure (see 862.5) is applied first.

Table 8.5 - Events Event
NCMNEWrec NCMNOTNEWre
C

Description
An N-CONNECT An N-CONNECT indication indication containing containing an NCM TPDU with NC-TYPE an NCM TPDU with NC-TYPE = NEW is received not NEW is received

NDlSind Collision TPD-NCexp TTR-NRexp Local decision Any TPDU NCONconf

An N-DISCONNECT indication A collision in the opening state as a result of association The timer TPD-NC expires The timer TTR-NC expires The transport entity may choose to initiate this transition Receipt of any TPDU on the network connection An C-CONNECT confirmation

as described

in 6.3.5b)

Table B.6 -Actions Action
NCONreq NCMNEW NCMNOTNEW NDlSreq NCONresp [l] [2] [3] I 141 La

Description
issue an N-CONNECT request to the network service Send an NCM TPDU with the NCONreq with NC-TYPE = NEW and locally allocated nc-reference Send an NCM TPDU with the NCONreq with NC-TYPE set to show the original source of allocation of the reference Issue an N-DISCONNECT request to the network service response to the network service lsst Je an N-DISCONNECT Start TPD-NC timer Start TTR-NC timer if not already running

1

1 The remotely initiated connection

for TFR-NC if locally allocated _ has been the winner. Re-assic fn any TCs from the loser and process the jncoming NCM TPDU as an NCMNEW in the CLOSED state for the winning reference Stop TTR-NC if running otherwise remove information that it has expired Stop TPD-NC Record with the nc-reference that a TPDU has been received that TTR-NC has expiied :ransmitted ..re received NCM TPDU has the RIGHT field set to the value RA, a NCMC TPDU is 1 the NS-user data parameter of N-CONNECT response

Freeze the nc-reference

(6) (71

in

1
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Table 8.7 - Predicates Predicate Pl P2 P3 P4 P5 P6 P7 Description -------I Incoming network connection unacceptable or the local entity is the winner of a collision Remote transport entity is not an owner of the network connection and local choice Local choice not to recover or TTR-NC has previously expired Local choice not to recover The remotely initiated network connection is the winner of collision resolution A TPDU has been received on a network connection associated with this nc-reference [see (7)] Assignment rights are "remote side" and N-CONNECT confirmation does not carry an NCMC TPDU

J

Table 8.8 - Notes Note (1) (2) (3) (4) (5) (6) Description DIAG TPDU with CODE = 0 may be sent The new connection is retained and the old connection disconnected Repeat the previous NCM except that NC-PREF may be different This is a protocol error Discard the "loser" after collision resolution The incoming network connection is disconnected and the old one retained

Table B.9 - States Note CLOSED OPENING OPEN RECOVERY PENDING Description Network connection is closed Network connection requested but not yet confirmed Network connection is open Attempting recovery of a failed network connection A non-owner of the network connection is waiting for recovery by the owner

6
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Table B.10 State Event

State Table

CLOSED

OPENING

OPEN

RECOVERY

PENDING

NCMNEWrec

Pl: NDlSreq CLOSED; not Pl: [9] NCONresp OPEN:

P6: (4) NDlSreq OPEN; not P6: [9] NCONresp NDlSreq (2) OPEN: NCONresp (2) NDlSreq OPEN NCONresp (2) NDIS req OPEh

NDlSreq (6) RECOVERY

P6: (4) NDlSreq PENDING; not P6: [9] NCONresp [6] OPEN;

NCMNOTNEWrec

(4) NDlSreq

Pl : NDlSreq

(1) RECOVERY; not Pl : NCONresp NDlSreq (2) (5) OPEN;

NCONresp [6] OPEN

Local decision NDlSind

NCMNEW OPENING Not P3: [2] NCMNEW (3) OPENING; P2 & P3: [3] CLOSED; (not P2) &
P3:

Not P4: NCMNOTNEW

PI
RECOVERY; P2 & P4: [3] CLOSED; P4 8 not P2: [l] PENDING;

Not P3: NCMNOTNEV RECOVERY; P3: [1,5] PENDING;

[l ,5]

PENDING; Collision Pl: NDlSreq (1 OPENING; not Pl: NDlSreq (2) 14731 CLOSED

TPD-NCexp Any TPDU TTR-NCexp NCONconf ;6] OPENING P7: [3] CLOSED; not P7: [5] OPEN; (71OPEN

-

[8] RECOVERY [5] OPEN

i
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8.11

Diagram for NCMS protocol operation
8.11.1.3 The initiator detects a collision with TYPE different from NEW 8.11.1.3.1 in OPENING state

This clause provides some tutortial information by giving examples of collision cases (see B.11 .l) and remoteiy initiated recovery (see 6.11.2). This clause is informative. 8.11 .l Collision case a collision on OPENING state

The other end is in RECOVERY

state

B.ll.l.l Both end detect with TYPE = NEW

NCONreq (NCM-NEW)

\ \ \ NCONind (NCM-NEW) NCONresp \ NDlSrnd

NCONreq (NCM-NEW)+

,

,

/i_

E::W) 1;

E:

\

NCONind (NCM-NEW)

-) +

NCONind (NCM-NEW)

NCONreq (NCM-YOURS)

The references are different but both ends have decided to associate the rec,eived NCM TPDU according to B.6.2.5b). B.11.1.2 Both ends detect a collision in RECOVERY state The entitiy in OPENING state (left side) accepts the incoming network connection and disconnects the PENDING one. 8.11.1.3.2 The other RECOVERY state end detects a collision in

NCONreq (NCM-NEW)

-)__
---) NCONind (NCM-NEW) NCONresp

, NCONconf -, A NDlSind -r' \ '

+

NCONreq (NCM-NEW) -i-

i

.

NCONind (NCM-NEW) r, NCONresp

+

NDlSind

NCONreq (NCM-MY)

---) / `/ /'

-

NCONreq (NCM-YOURS)

NDlSind NCONreq (NCM-NEW) NCONind

NDlSind

NCONind -/ (NCM-YOURS)

\

--)

NCONind (NCM-MY)

NCONreq (NCM-YOURS) NCONind (NCM-NEW)

Both entities will use the collision resolution algorithm and one of the two network connections will be disconnected.

Both entities dismmect the entity on the left.

the network

connection

initiated by
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EL1 1.2

Remotely initiated recovery
NCONreq

(NCM-NEW) NCONreq _.+ (NCM-NEW)

--

--)

NCONind

(NCM-NEW)

NCONconf

-

r

.

.

+-

NCONresp

NDlSind NCONreq

X.

I
1

\

(NCM-YOURS)
-bNDlSind

1
NCONind (NWVO"F$-

I

`I

'

r

IC_

NCONreq

(NCM-YOURS)

The entity connection connection.

on the left detects an incoming in OPEN state and disconnects

network the old

The entity connection concection.

on the left detects an incoming in OPEN state and disconnects

network the old
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Annex Cl)
(normative)

PIGS Proforma

c.1
C.l.l

General
Symbols used

Status symbols: M 0 O.<n> Mandatory. Optional to implement. Optional but support is required. If implemented the feature may or may not be used.

of at least one of the group of options labelled by the same numeral <n> in this PIGS proforma

<index>:

This predicate symbol means that the status following it applies only when the PIGS states that the feature identified by the index is supported. In the simplest case, <index> is the identifying tag of a single PIGS item. <index> may also be a Boolean expression composed of several indices. When this group predicate is true the associated clause should be completed.

<index>::

Support symbols: Yes No N/A C.1.2 Supported. Not supported. Not applicable. Instructions for completing the PIGS proforma of clauses. Answers to indicate a restricted to the choice

The main part of the PIGS proforma is a fixed-format questionaire divided into a number questionnaire are to be provided in the rightmost column either by simply marking an answer (such as Yes or No) or by entering a value of a range of values or entering what action is taken.

`1 Copyright

release for PIGS proforma

Users of this International Standard may freely reproduce the PIGS proforma in this annex so that it can be used for its intended purpose and may further publish the completed PICS.
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c.2
C.2.1

Identification
Implementation identification

Contact

point for queries about the PIGS Names(s) and Version(s) -

Implementation

Other information necessary for full identification e.g. name(s) and vers:oc(s) of machines and/or operating systems. Svstein Name(s) L---L_"__1_
NOTES 1 Only the first three items are required requirement for full identification. 2

for all implementations;

other

infonat'2n

may be completed

as appropriate

in meeting

the

The terms Name and Version shou!d be interpreted

appropriately

to correspond

with a supplier's terminology

(e.g. Type, Series, Model)

C.2.2

Protocol

Summery

----______
identification of p:o?ccci

__-__specihcation ISO/iEC 80731992 (E)

--.__-__I
identification Corriyenda

-__---

__.-

CCITT X.224 Reference ISOAEC FiG73:1992

Number: X.224 (1988) __-

of Amendments and to this PiCS proforma which

have been compieted _l__l___-Prct~col Version(s) ___-__-~

as part of this PIGS Version 1

supported items been required?

I i

Have any Exception

NoI 1

Yesi I
X.224) -

(The ans'wer Yes means that the implementation --

does not conform to ISOAEC 8073:1992KClTT

IDate

of statemen
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c.3

Indices used in this annex
C.6.1 C.6.2 C.6.2 C.5 C.14 C.14 Cl 4 C.13.1 C.13.1 C.13.1 C.13.2 C.13.2 C.13.2 C.13.3 C.13.3 C.13.3 C.13.4 C.13.4 C.13.4 c.11.1.2 c.11.2 C.8 Cl 1.3 c.11.3 C.1 1 .3 c.11.4 C.11.4 C.lf.4 C.ll.4 C.11.4 c.11.5 C.11.5 C.11.5 C.ll.5' C.11.6 C.l 1.6 C.11.6 C.11.6 C. 11.6 C.11.7 c.11.7 C.ll.7 C.11.7 C.11.7 C.ll.7 ISO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c.5 N...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c.7 NAC .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.15.1 NEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.15.4 NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.15.1 NUC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.15.6 C.15.7 NUF.. ...................................................................... C.17 OT.. ........................................................................ C.16.1 PE .......................................................................... C.16.1 PE4L ...................................................................... C.15.2 RC.. ........................................................................ C.15.2 RC4a.. .................................................................... RN.. ........................................................................ C.12.1.2 ROA.. ..................................................................... C.15.11 C.16.2 RR.. ........................................................................ C.12.2 R4AKch.. ................................................................ C.12.2 R4CCch ................................................................. C.12.2 R4DCch ................................................................. C.12.2 R4DRch ................................................................. C.12.2 R4DTch.. ................................................................ C.12.2 R4EAch.. ................................................................ C.12.2 R4EDch ................................................................. C.12.2 R4ERch ................................................................. c.10 SER ....................................................................... C.10 SER4L ................................................................... c.10 SN.. ........................................................................ c.10 ST .......................................................................... c.17 TA .......................................................................... ~15.5 TED.. ...................................................................... ~15.3 TS .......................................................................... c.9.1 TOF.. ....................................................................... c.15.3 TOS ........................................................................ c.9.2 Tl F.. ....................................................................... ~15.3 TlS ........................................................................ c.9.3 T2F.. ....................................................................... c.15.3 T2S ........................................................................ c.9.4 T3F.. ....................................................................... c.15.3 T3S ........................................................................ c.9.5 T4F.. ....................................................................... c.15.3 T4S ........................................................................ C.16.3 UI ........................................................................... ~15.9 UNED ..................................................................... C.15.8 UNRC.. ................................................................... USA ....................................................................... C.15.10

A .............................................................................
C ............................................................................. C4L ........................................................................ CCT.. ...................................................................... DRCC.. ................................................................... DRCR.. ................................................................... DRDR.. ................................................................... DllCC .................................................................... DlICR .................................................................... DlIDR .................................................................... D216C .................................................................... DPICR .................................................................... D2lDR .................................................................... DBICC .................................................................... D3lCR .................................................................... DBIDR .................................................................... D4lCC .................................................................... D4lCR .................................................................... D4lDR .................................................................... IC.. .......................................................................... ICR.. ....................................................................... IR.. ................. . ........................................................ IOCC.. ..................................................................... IOCR.. ..................................................................... IODR.. ..................................................................... IlCC.. ..................................................................... IlCR.. ..................................................................... IlDR ....................................................................... IlDT.. ...................................................................... IlER ....................................................................... 12cc.. ..................................................................... 12CR.. ..................................................................... 12DR.. ..................................................................... l2ER ....................................................................... 13CC.. ..................................................................... 13CR.. ..................................................................... 13DR.. ..................................................................... 13DT.. ...................................................................... 13ER.. ..................................................................... l4AK ....................................................................... l4CC.. ..................................................................... l4CR.. ..................................................................... 14DR.. ..................................................................... 14DT.. ...................................................................... l4ER .......................................................................
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c.4

Based standard/recommendation

conformance

Does the implementation Does the implementation

claim conformance claim conformance

to ISO/IEC

8073?

1 Yes I Yes

No No

) 1

to CCITT X.224?

c.5

General statement of conformance

IS0
CCT

Are all mandatory Are all mandatory

features features

of ISO/IEC

8073 implemented?

Yes Yes

No No

of X.224 implemented?

Note -Answering

`No' to this question indicates non-conformance to the International Standard/Recommendation.

C.6
C.6.1

Protocol implementation
Annex B - NCMS

index Al Network connection management procedures

References Annex B

Status 0

support Yes No

C.6.2

Classes implemented

Index co Class 0

Class

References 14

Status IS0:O.l CCT:M co:0 IS0:O.l CCT:O c2:o c2:o fSO:C2:0 CCT:NIA

support
Yes No

Cl c2

Class 1 Class 2

14 14

Yes Yes

No No

c3 c4 C4L

Class 3 Class 4 operation Class 4 operation over CONS over CLNS

14 14 14

Yes Yes Yes

No No No
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c.7

NCMS functions

Index N2 N3 Network connection management

item

References 8.6.2.1 8.7.6.2. 8.7.7

Status 0 0

support Yes Yes No No

Diagnostic

N4

Active network

connection

recovery

8.7.4.2

0

Yes

No

The folio' ____Index N5

ing is mandatory

if the predicate

is true Item References 0.7.4.3 Status N2 OR N4: M 0 support Yes No

Passive

network connection

recovery

N6

Is an NCM TPDU with assignment N-DISCONNECT request?

right set to RA always rejected with

B.6.3

Yes

No

C.8

Initiator/responder capability for protocol classes 0 - 4

Index 1 IRl IR2

/ 1 Initiating CRTPDU 1 Responding
to CR TPDU

References

Status

I

support

I

1 1

14.5 a) 14.5 a)

c.9
C.9.1

Supported functions
Supported functions for class 0 (CO::) if class 0 is supported Function Assignment to network connection when operating over CONS References 6.1.1 6.2 6.3 6.3 6.5 6.6 over CONS (implicit) 6.7.1 6.8 when operating over 6.9.1 Status M M M M M M M M M support Yes Yes Yes Yes Yes Yes Yes Yes Yes

The following Index TOFl TOF2 TOF3 ToF4 ToF5 TOF6 _ TOF7 TOF8 TOF9

fu_nctions are mandatory

TPDU transfer Segmenting Reassembling Connection Connection establishment refusal

Normal release when operating Error release when operating Association CONS Treatment

over CONS connection

of TPDUs with Transport

TOFlO

of protocol

errors when operating

over CONS

6.22.1

M

Yes
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Supported

functions

for class 1 (Cl::)
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C.9.3 Supported functions

for class 2 (C2::)

onnection establishment

T2Fl3 T2Fl4 T2F15 T2F16

Demultiplexing when operating over CONS Explicit flow control (with) Treatment of protocol errors when operating over CONS Multiplexing when operating over CONS

6.15 6.16 6.22.1 6.15

M M M M

Yes Yes Yes Yes

The following functions or elements of procedure are optional if class 2 is supported Index T2F17 T2F18 T2F19 Concatenation Data TPDU numbering (extended) Explicit flow control (without) Function References 6.4 6.10 6.16 Status 0 0 0 support Yes Yes Yes No No No

6

109

IS 13919

: 1994
8073

ISOAEC

: 1992

C.9.4

Supported

functions

for class 3 (C3::)

The following functions are mandatoty if class 3 is supported Index T3Fl T3F2 T3F3 T3F4 T3F5 T3F6 T3F7 T3F8 T3FQ T3FlO T3Fll T3F12 T3F13 T3F14 T3F15 T3F16 T3F17 T3F18 T3FlQ Function Assignment to network connection when operating over CONS TPDU transfer Segmenting Reassembling Separation Connection establishment Connection refusal Normal release when operating over CONS (explicit) Association of TPDUs with Transport connections when operating over CONS .Data TPDU numbering (normal) Expedited data transfer when operating over CONS (Network normal) Reassignment after failure when operating over CONS Retention and acknowledgement of TPDUs Retention until acknowledgement of TPDUs (AK) Resynchronization Demultiplexing when operating over CONS Explicit flow control Frozen references Treatment of protocol errors when operating over CONS Multiplexing when operating over CONS References 6.1.1 6.2 6.3 6.3 6.4 6.5 6.6 6.7.1 6.9.1 6.10 6.11.1 6.12 6.13.4.1 Status M M M M M M M M M M M M M M M M M M M support Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

6.14 6.15 6.16 6.18 6.22.1 6.15

The following functions are optional if class 3 is supported Index T3F20 T3F21 T3F22 Concatenation Data TPDU numbering (extended) Retention and acknowledgement of TPDUs Use of request acknowledgement Function References 6.4 6.10 6.13.4.3 Status 0 0 0 support Yes Yes Yes No No No
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C.9.5

Supported

functions

for ciass 4 (C4 or C4L::)

The following functions are mandatory Index T4Fl T4F2 T4F3 T4F4 T4F5 TPDU transfer Segmenting Reassembling Separation Connection establishment Function References 6.2
6.3

Status M M M M M

support Yes Yes Yes Yes Yes

6.3 6.4 6.5

T4F20 T4F21 T4F22

Demultiplexing when operating over CONS Treatment of protocol errors when operating over CONS Recombining when operating over CONS

6.15 6.22.1 6.23

M M M

Yes Yes Yes

The following functions are mandatory if class 4 is operateti over CLNS Index T4F23 T4F24 T4F25 T4F26 T4F27 Transmission over CLNS Normal release when operating over CLNS (explicit) Association of TPDUs with Transport connection when operating over CLNS Expedited data transfer when operating over CLNS (Network normal) Treatment of protocol errors when operating over CLNS
111

Function

References 6.12 6.7.2 6.9.2 6.11.2 6.22.2

Status M M M M M

support Yes Yes Yes Ves Yes
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The following functions are optional if class 4 is operated over CONS Index T4F33 Function Splitting and recombining when operating over CONS References 6.23 Status 0 support Yes No
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Cl 0

Supported

TPDUs
which constitute their fixed parts are mandatory References -13.1 13.1 13.1 13.1 13.1 -___ -~_--___~__ 13.1 13.1 -. if a correspondinq _ predicate Status IRl:M IR2:M IR2:M IRl:M IR2:M ___---._____ IRl:M --___ Cl OR C2 OR C3 OR C4 OR C4L:M Cl OR C2 OR C3 OR C4 OR C4L:M _ M M ___-_I_ Cl OR C2 OR C3 OR C4 OR C4L:M Cl OR C2 OR C3 OR C4 OR C4L:M -_~~ Cl OR C2 OR C3 OR C4 OR C4L:M ~~.~-l__-__l~ Cl OR C2 OR C3 OR C4 OR C4L:M Yes __ support No No No No No No No .~ No in the

The following TPDUs and the parameters status column is true Index STl ST2 _ ST3 ST4 ST5 ST6 ST? ST8 DC supported CR CR cc CC OR DR PC supported supported supported supported supported supported supported TPDUs

I__.-I_

on transmission on receipt on transmission on receipt on transmission on receipt on transmission ----___.__ on receipt

Yes ___.~_ Yes _~ .___~ Yes Yes _~~_._~ Yes Yes Yes ~._.___~ Yes

13.1

.-__
Yes ._~ ___ Yes

__

ST9 ST1 0

DT DT

supported supported supported
--_I_

on transmission on receipt on transmission
-

-.

13.1 13.1 13.1

ST" I ED I
ST1 2 ED ST13 AK

No __

supported

on receipt -~

13.1

supported

on transmission

13.1 _

ST14

AK

supported

on receipt

13.1 _____~

- -___-

ST15

EA

supported

on transmission

13.1 C4 OR C4L:M

ST1 6

EA

supported

on receipt C4 OR C4L:M

ST1 7 ST1 8 ST1 9 ~~

RJ RJ ER

supported

on transmission

_~._~ ~___~

~~

_~

~l__

Cl OR C3:M

supported on receipt ____-. supported on receipt

~___._~

~

State for which classes,any, Index ~SERo SERl SER2 .--_ . ~.____________~ Class 0 ____.

ER is supported Class

on transmission ____~ --~ _

----

-..-.

~.. -

Class 1 --_I~ Class 2

_~-

~~ ~~__

~~.____~

SER3 Class 3 -~___-~-~--I_-__~-~SER4 SER4L Class 4 over CONS Class 4 over CLNS

~-I_-

~_.

~~ _I_~_~~

___
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The following Index SN3 SN4 SN5 SN6 SN7 SN8 Pl: r

TPDUs are mandatory

if a corresponding TPDUs

predicate

in the status column is true. Refarences 8.81 .-B.8.1 B.8.1 B.8.1 B.8.1 B.8.1

I /

Status N2:M N2:M N3:M N3:M SN4 AND NOT N6:M Pl:M

support Yes Yes Yes Yes Yes Yes No No No No No No

NCM NCM DIAG DIAG NCMC NCMC _-

supported supported supported supported supported

on transmission on receipt on transmission on receipt on transmission

supported on receipt _-____value In IC5 is "receiver".

SN3 and the only supported

C.11
Cl1 .I C.ll.l.l

Supported
Supported

parameters
parameters

of issued TPDUs

for NCMS (Al ::)

NCM TPDU (SN3::)

_What are the allowed values of the following parameters for a NCM TPDU? I Allowed values index ( Supported parameters References
-Iclic-,,---_-IC2 k Ic3 IC4 .--. ---? __ !C5 __~--`_ t I__NC-preference -~~8.8.3.3 c) 8.8.3.3 d) 8.8.3.3 e) 8.8.3.3 1) right 8.8.3.3 g) New, My, Yours Highest, Medium, Resolution Do not, Do Receiver, Sender, All Lowest

Supported

values

/ NC-coilision
NC-recovery ___ NC-assignment

C.11.2

Parameter

values for CR TPDU (Cl:: OR C2:: OR C3:: OR C4:: or C4L::) parameter is issued in a CR TPDU it is mandatory that References

If the additional

options selection

I*.

3 Bats 8 and 7 shall be set to zero
class in the CR is 2, 3 or 4 References' Is class 0 always offered as an alternative class? 14.4 Status 0 CCT:M

13.3.4 g)

If the preferred Index ICR2

support Yes Yes No No
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C.ll.3

Supported

parameters

for class 0 TPDUs

(CO::)

The following parameters are optional if a CR TPDU is issued with preferred class 0 Index IOCR6 IOCR7 lQCR8 IOCR9 Called TSAP-ID Calling TSAP-ID TPDU size Preferred maximum TPDU size Supported parameters References 13.3.4 a) 13.3.4a) 13.3.4 b) 13.3.4 c) Status 0 0 0 0 support Yes Yes Yes Yes No No No No

The following parameters are optional if a CC TPDU is issued in class 0 Index 10CC6 IOCC7 10CC8 Called TSAP-ID Calling TSAP-ID TPDU size Supported parameters References 13.4.4 13.4.4 13.4.4 Status 0 0 0 I o support Yes Yes Yes 1 Yes No No No No I

IOCC9 1 Preferred maximum TPDU size The following parameter is optional if a DR TPDU is issued in class 0 Index IODR4 Additional information Supported parameter

I

13.4.4

References 13.5.4 a)

Status 0

support Yes No

Cl 1.4

Supported

parameters

for class 1 TPDUs

(Cl::)

IS 13919 : 1994
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The following Index llCC6 llCC7 llCC8 llCC9 I1 CC1 0 I1 CC1 1 I1 CC1 2 I1 CC1 3 I1 CC1 4 I1 CC1 5

parameters

are optional

if a CC TPDU is issued in class I parameters References 13.4.4 13.4.4 13.4.4 Status 0 0 0 0 0 0 0 0 0 support Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No -13.4.4

Supported Called TSAP-ID Calling TSAP-ID TPDU size Protection Additional parameters option selection

13.4.4 13.4.4 13.4.4 13.4.4 13.4.4 13.4.4

' Throughput
Residual Priority Transit delay Preferred maximum TPDU size error rate -

The following Index I1 DR4

parameter

is optional

if a DR TPDU is issued in class I Supported parameter References 13.5.4 a)

Additional

information

The following
index I1 ER3

parameter

is optional

if a ER TPDU is issued in class 1 Supported parameter References ----_

Invalid TPDU

The following Index llDT4

Parame!er

is mandat+n

a DT TPDU if request of acknowledgement parameter

has been selected

Supported ROA

0
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C.11.5

Supported

parameters

for class 2 TPDUs

(C2::) class 2 References 133.4 a) Status 0 0 0 0 0 0 0 0 0 0 0 0 support Yes Yes No No

-~The following Index t2CR6 12CR7 12CR8 l2CR9 12CRlO 12CR11

parameters

are optional

if a CR TPDU is issued with preferred parameters

Supported Called TSAP-ID Calling TSAP-ID TPDU size Version number parameters option selection -----.____--_____~ ____--

13.3.4 a) 13.3.4 b) 13.3.4 d) 13.3.4 e) 13.3.4 g) -__ -~- _~____ 13.34 h)

Yes No __..___ Yes Yes Yes Yes Yes Yes Yes Yes Yes .___ No No No No No No No No No

Protection Additional

13.3.4 k) 13.3.4 m) 13.3.4 n) 13.3.4 p) 13.3.4 c) -__

The followingparameters are optional if a ~_. CC TPDU ___..~_. ~. ~~~._ ._~_~_..__ ~~ _ IS rssued in class 2 ___ _ Index ._I_12CC6 12CC7 l2CC8 ____. 12cc9 12CClO 12CCll 12CC12 12CC13 ____ Called TSAP-ID Calling TSAP-ID TPDU size Protection Additional Throughput Residual Priority error rate parameters option" selection -__I_ __I_ _____~ Supported parameters References 13.4.4 _I13.4.4 --__ 13.4.4 __~___~___ .___13.4.4 13.4.4 Status ____~_ 0 0 0 __~~_ _ support ---__ Yes Yes Yes Yes _Yes No No No No No

0 _-.___ 0

The following LZI-

parameter

is optional

if a DR TPDU is issued in class 2 Supported parameter References Status -LFI

L---L
12DR4 LdJ1 12ER3

Additional

information

The followingparameter

is optional

if an ER TPDU is issued in class 2 parameter References Status ~0 r

___. support -I 1 Yes q No ]

I___ Supported ( Invalid TPDU

1 13.12.4 a) ]
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C.11.6

Supported

parameters

for class 3 TPDUs

(C3::)

13CR11 13CR12 13CR13 13CR14 13CR15

Additional option selection Alternative protocol class Throughput Residual error rate Priority

13.34 g) 13.3.4 h) 13.3.4 k) 13.3.4 m) 13.3.4 n) 13.3.4 p) 13.3.4 q) 13.3.4 c)

0 0 0 0 0 0 0 0

Yes Yes Yes Yes Yes Yes Yes Yes

No No No No No No No No

13CR16. Transit delay 13CRl7 Reassignment time Preferred maximum TPDU size

I 13CR18

The following parameters are optional if a CC TPDU is issued in class 3 Index 13CC6 13CC7 13CC8 l3CC9 13CClO 13CCll 13CC12 Called TSAP-ID Calling TSAP-ID TPDU size Protection parameters Additional option selection Throughput Residual error rate Supported parameters References 13.4.4 13.4.4 13.4.4 13.4.4 13.4.4 13.4.4 13.4.4 Status 0 0 0 0 0 0 0 1 0 0 0 support Yes Yes Yes Yes Yes Yes Yes ) Yes No No No No No No No No )

1 13CC13 ] Priority I3CC14 13CC15 Transit delay Preferred maximum TPDU size

1

13.4.4 13.4.4 13.4.4

The following parameter is optional if a DR TPDU is issued in class 3 Index l3DR4 Additional information Supported parameter References 13.5.4 a) Status 0 support Yes No

The following parameter is optionai if a ER TPDU is issued in class 3 Index 13ER3 Invalid TPDU Supported parameter References 13.12.4 a) Status 0 support Yes No

*
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The following Index 13DT4

parameter

is mandatory

in a DT TPDU if request of acknowledgement parameter

has been selected References 13.73 a) Status M support Yes No

Supported ROA

C.11.7

Supported

paiameters

for class 4 TPDUs

(C4 OR C4L::)

support Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Ye9 Yes No No No No No No No No No No No No No

The following Index 14CR20

parameters

are optional

if a CR TPDU is issued with preferred parameter

class 4 over CONS References 13.3.4 h) Status 0 support Yes No

Supported Afternative protocol class
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14CC13 14CC14 14CC15 14CC16 14CC17

Residual Priority

error rate

13.4.4 13.4.4 13.4.4 TPDU size 13.4.4 13.4.4

0 0 0 0 0

Yes Yes Yes Yes Yes

No No No No No

Transit delay Preferred Inactivity maximum time

.- The following Index 14DR4

parameter

is optional

if a DR TPDU is issued in class 4 Supported parameter References 13.5.4 a) Status 0 support Yes No

Additional

information

The following index 14DT4

parameter

is mandatory

in a DT TPDU if request of acknowledgement parameter

has been selected References 13.7.3 a) Status M support Yes No

Supported ROA

The following Index l4AK4

parameter

is mandatory

in an AK TPDU if issued in class 4 parameter References 13.9.4 c) Status 0 support Yes No

Supported Flow control confirmation

If the implementation TPDUs is mandatory. G-J---14AK5 ) Subsequence

can reduce credit and does so in the manner Otherwise complete item 14AK5 Supported number parameter

outlined

in 12.2.3.8.2 References

then subsequence Status ( 0

number support ) Yes

in AK

) 13.9.4 b)
in an AK TPDU if selective Supported parameter acknowledgement

No

1

The following Index l4AK6

parameter

is optional

has been negotiated. References 13.9.4 d) Status 0 support Yes No

Selective

acknowledgement

parameters

The following Index l4ER3

parameter

is optional

if an ER TPDU is issued in class 4 Supported parameter References 13.12.4 a) Status 0 support Yes No

Invalid TPDU

c

120

IS 13919 ISO/IEC

: 1994 8073 : 1992

Cl 2

Supported

parameters

for received TPDUs
and processing ail possible parameters for all

Implementors should be aware that implementations shall be capable of receiving possible TPDUs, dependent upon the class and optional functions implemented. C.12.1 C.12.1.2 Supported parameters for NCMS (Al::)

NCM TPDU (SN4::) parameters References 683.3 883.3 -___ c) d) for a NCM TPDU? Allowed values New, My, Yours Highest, Medium, Resolution Do not, Do Receiver, Sender, All Lowest Supported values

What are the allowed receive values of the following index RN1 RN2 RN3 __NC-type NC-preference NC-collision Supported parameters

8.8.3.3 e) B.8.3.3 f)

~wnt

right

I__

8.8.3.3 g)

C.12.2 TPDUs

in class 4 (C4 OR C41::) has been selected then it is mandatory TPDUs to process a checksum parameter References 13.4.4 in the following Status M 4 ) / Yes Yes Yes Yes Yes Yes Yes TPDUs

If use of checksum Index R4CCch R4DRch R4DCch R4DTch R4EDch R4AKch R4EAch R4ERch

CC TPDU

/ DR TPDU [ DC TPDU
DT TPDU ED TPDU AK TPDU EA TPDU ER TPDU

1 13.54 b) 1
13.6.4 13.7.4 13.8.4 13.9.4 a) 13.10.4 13.12.4 b)

1 )

M M

1 )
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C.13

User data in issued TPDUs
request, T-CONNECT response or T-DISCONNECT request. Then it shall be

A TS-user may issue data with a T-CONNECT possible to send user data as follows: C-13.1 Class 1 (Cl::)

Index Dl ICR Dl ICC Dl IDR

User data User data of up to 32 octets in a CR with preferred User data of up to 32 octets in a CC User data of up to 64 octets in a DR class 1

References 13.3.5 13.4.5 13.5.5 --__-__-

Status M M ____~ M -

C.13.2

Class 2 (C2::)

User data of up to 32 octets in a CR with preferred User data of up to 32 octets in a CC User data of up to 64 octets in a DR

class 2

C.13.3

Class 3 (C3::)

Index D3tCR D3lCC D31DR

-

User data class 3

References 13.3.5 13.4.5 13.55

Status M M M

support Yes Yes Yes

User data of up to 32 octets in a CR with preferred User data of up to 32 octets in a CC User data of up to 64 octets in a DR

C.13.4

Class 4 (C4 or C4L::)

Index D41CR D4lCC D4lDR

User data User data of up to 32 octets in a CR with preferred User data of up to 32 octets in a CC User data of up to 64 octets in a DR class 4

References 13.3.5 13.4.5 13.5.5

Status M M M

support Yes Yes Yes
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C.14

User data in received

TPDUs

For classes 1 to 4, if it is

ossible to initiate a CR TPDU then it shall be possible to receive the following. References

64 octets of user data in a DR TPDU

For classes 1 to 4, if it is possible to respond to a CR TPDU then it shall be possible to receive the following. Index DRCR 32 octets of user data in a CR TPDU User data References 13.3.5

C.15
C.15.1

Negotiation
Class negotiation - initiator class then the following holds. References The preferred class in the CR TPDU may contain any of the classes supported implementation by the 6.5.4 h)

If it is possible to initiate a CR TPDU in a particular index NC

What class(es) Index NACl NAC2 NAC3 NAC4 NAC5

is (are) contained

in the alternative class

class parameter

if the preferred References 6.5.4 h) 6.5.4 h) 6.5.4 h) 6.5.4 h) 6.5.5 h)

class is: Allowed values None, 0, 1 None, 0, 2 None, 0, 1, 2, 3 None, 0, 1, 2, 3, 4 None Supported values

Preferred

Class 1 Class 2 Class 3 Class 4 over CONS Class 4 over CLNS

c
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C.15.2

Class

negotiation

- responder

Index RCO

Preferred

class

__ with if CR

References 6.54 h) Table 3

Allowed

response

Supported

response

-

What classes can you respond proposes only class O?

0 or connection refused depending on classes supported 0, 1 or connection refused depending classes supported 0, 1 or connection refused depending classes supported

RCl

What classes can you respond with if CR proposes only class l?

6.5.4 h) Table 3

on _ on __I__

RCl a

What classes can you respond with if CR proposes class 1 as preferred class and the alternative class parameter is present? What classes can you respond with if CR proposes only class 2?

6.5.4 h) Table 3

RC2

6.5.4 h) Table 3

2 or connection refused depending on classes supported 0, 2 or connection refused depending on classes supported and coding of alternative class 2,3 or connection refused depending classes supported 0, 1, 2, refused classes coding claSS

What classes can you respond with if CR proposes class 2 as preferred class and the alternative class parameter is present?

6.5.4 h) Table 3

What classes can you respond with if CR proposes only class 3?

6.5.4 h) Table 3

on __-

you respond with if CR proposes class 3 as preferred class and the alternative class parameter is present?

6.5.4 h) Table 3

3 or connection depending on supported and of alternative

RC4

What classes can you respond with if CR proposes only class 4?

6.5.4 h) Table 3

2, 4 or connection refused depending classes supported

on

RC4a

What classes can you respond with if CR proposes class 4 as preferred class and the alternative class parameter is present?

6.5.4 h) Table 3

---__

0, 1, 2, 3, 4 or connection refused depending on classes supported and coding of alternative class -

C.15.3

TPDU size negotiation

I-Index TSl ____._ TS2

References If maximum TPDU size is proposed in a CR TPDU then the initiator shall support all TPDU sizes from 128 octets to the maximum proposed. If the preferred maximum TPDU size parameter is used in a CR TPDU then the initiator shall support all TPDU sizes, except 0, that are mu!tiples of 126 octets up to the preferred maximum proposed. _______ 14.6

Status M

support Yes

14.6 e)

14CR18:M

Yes

No

I
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Index TO%

TPDU size What is the largest value of the maximum TPDC size parameter in a CR TPDU with preferred clasc O?

Reference! 14.6 e)

S

Allowed values NOT IOCR9: One of 128, 256, 512,1024,2048 IOCR9: One of nxl28 with n = 1, 2, 3, . NCT IOCC9: One of 128, 256, 512, 1024, 2048 IOCC9: One of nxl26 with n = 1, 2, 3, NOT I1 CR1 8: One of 128, 256, 512, 1024, 2048, 4096, 8192 I1 CR1 8: One of nxl28 with n = 1, 2, 3, NOT I1 CC1 5: One of 126. 256. 512, 1024. 2046. 4096, 8192 I1 CC1 5: One of nxl26 with n = 1, 2, 3, ,__ NOT 12CR17: One of 128. 256,512,1024, 2048, 4096, 6192 12CR17: One of nx128 with n = 1, 2, 3, ,_. NOT 12CC15: One of 128, 256, 512, 1024, 2046. 4096, 8192 12CC15: One of nxl28 with n = 1, 2, 3, _.. NOT 13CR16: One of 128. 256, 512, 1024. 2040, 4096, 6192 13CR16: One of nx128 with n = 1. 2, 3, IVOT 13CC15: One of 126, 256, 512, 1024, 2048. 4096, El192 I;3CC15: One of nxl2.5 ,with n = 1, 2. 3, .._

Supported

values

TOS2

What is the largest value of the maximum TPDl size parameter which may be sent in a CC TPDU when class 0 is selected? ---

14.6 e)

]
14.6 e)

~.____

TlS1

What is the largest value of the maximum TPDl size parameter in a CR TPDU with preferred class l?

T1S2

What is the largest value of the maximum TPDL size parameter which may be sent in a CC JPDU when class 1 is selected?

14.6 e)

__--

T2Sl

What is the largest value of the maximum TPDL size parameter in a CR TPDU with preferred class 2?

14.6 e)

T2S2

What is the largest value of the maximum TPDL size parameter which may be sent in a CC TPDU when class 2 is selected?

14.6 e)

.-T3Sl

,VVhat is the largest value of the maximum TPDU
size parameter ,:lass 3? in a CR TPDU with preferred

14,6 e)

T3S2

\What is the largest value of the maximum TPDU
$ size

14.6 e)

parameter which may be sent in a CC fPDU when class 3 is selected?

-~ T4Sl
\ Nhat is the largest < size parameter in C :lass

value of the maximum TPDU a CR TPDU with preferred

14.6 e)

IVOT l4CR: 8: One of 128,
256, 5i 2, 1024, 2048,

4?

T4S2

\ what is the largest value of the maximum JPDU ssize parameter which may be sent in a CC 1-PDU when class 4 is selected?

14.6 e)

1 1096, 8192 I4CR16: One of nx! 23 iNith r. = 1. 2, 3. -.._ __ ._.. .._ _~ I`JOT i4Ci:!6. 01e c! 128, ;256 512, i Z4, 2048. /[ _1096. 6192 4%: 6: One of nx126 ~;,n n = 1, 2, 2, .,,

c
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C.15.4

Use of extended

format

Index

Extended

format

References

Allowed values normal, extended. normal, extended normal, extended normal, extended normal, extended normal, extended

Supported values

NEFl

What fclniats

can you propose

in the CR TPDU in class 2?

6.5.4 n)

NEF2

What formats can you propose

in the CR TPDU in class 3?

6.54

n)

NEF3 --NEF4

What formats can you propose - -_.-

in the CR TPDU in class 4?

6.5.4 n) 6.5.5 n) 6.5.4 n)

I
NEF5

What formats can you select in CC when extended proposed in CR in class 2? -___What formats can you select in CC when extended proposed in CR in class 3? What formats can you select in CC when extended proposed in CR in c!ass 4?

has been

has been

6.5.4 n)

NEF6

has been

6.5.4 n) 6.5.5 n)

C.tS.5

Expedited

data transport

service

I
I

t-

`nuex-TED1
[ Expsdiied

References data indication in CR and CC TPDU 6.5.4 t) 6.55 r)

Status M

support Yes

I i____i_____.

C.15.S

Non-use

of checksum

((C4 OR C4L) AND T4F29::)

Index ,__~_I N?ICt

i

I
___~

Non-use

of checksum

/ What proposals can you make in the CR? I 1 What proposals can you make in CC when non-use of checksum 1 been proposed in CR?
has 6.5.4 p) 6.5.5 p) non-use, use

NUC2

C.15.7

Explicit

flow

control

(C2 and T2F19::)

Index

1 I
What proposals

Explicit flow control

References

Allowed values non-use, use non-use, use

Supported values

NUFl

can you make in the CR?

6.5.4 r)

NUF2

What proposals can you make in CC whan non-use control has been proposed in CR?

of explicit flow

6.5.4 r)

(r

__

~-
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C.15.8

Use of network

receipt confirmation

(Cl and Tl F21::)

,
Index Network receipt confirmation References Allowed values non-use, use non-use, use Supported values

UNRCl -UNRC2

What proposals

can you make in the CR?

6.5.4 s)

What proposals can you make in CC when use of network confirmation has been proposed in CR?

receipt

6.5.4 s)

C.15.9

Use of network

expedited

data (Cl and Tl F20::)

Index

Network

expedited

data

References

Ailowed values non-use, use non-use, use

Supported values

UNEDl

What proposals

can you make in the CR?

6.5.4 s)

UNED2

What proposals can you make in CC when use of network data has been proposed in CR?

expedited

6.5.4 s)

J

c.15.10

Use of selective

acknowledgement

Index

Selective

acknowledgement

References

Allowed values Yes, No

Supported values

USA1

Is use of selective

acknowledgement

proposed

in CR TPDUs?

6.5.4 u) 6.5.5 s) 6.5.4 u) 6.5.5 s)

USA2

Is use of selective acknowledgement been proposed in a CR? -__.__

selected

in a CC when it has -

Yes, No

c.15.11

Use of request

of acknowledgement

______-_-__
Index Request of acknowledgement

--._ _--

.-.. ..- _~---

- - -._.

____~

ROAl .-ROA2 -

Is use of request __-

of acknowledgement _-_____.__--__

proposed

in CR TPDUs"

Is use of request of acknowledgement been proposed in a CR? --..-.. --.- ---... - ^

selected

in a CC when it has
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C.16
C-16.1

Error handling
Action on receipt of a protocol error ---

Index

item

References

Allowed values CO: ER, NDISreq, NRSTrzq. Discard

1 Supported values

Class 1

Cl: ER, DR, N,DISreq.

1

Class 2 r.---+_---_-_--------_ Ciass 3

--~*/C3: ER, DR, NDlSreq, NRSTreq, Discard 6.22.1.3 C4: ER. DR. NDISreq, NRSTreq, Discard -__-C4L: ER. DR, Discard t

'
I

Class 4 over CONS

_

-

I_-.___I_._._____Class40verCLNS _ I "2'L2.3_
PE4L

1

C.56.2

Actions

an receipt of an inva!id or undefined
_---._-----.----.

parameter
-_______--_

in a CR TP5U

_____ -----I I Index 1
! /

Event

r
as

___._7__
References

..--- ~__ ---__ /
Status T support

RR1
RR2

k ----

j A cammeter not deiined in IS0 8073 shall be ignored : --.--__ .____ _-_ .._.-____

/

/

I--.--+_-.-_.-----.

! An invaiid value in the alternative protocol class parameter shall be / treated as a protocol error
-----.shall be treated

1
4

F-!Fr.-j i An invaiid vaiue in the class and option parameter j a protocol error

j
I

RR4

I-un receipt of the additional j h?s 4 to 1 if not meaningful
option se&lion parameter

option selection parameter bits 8 to 5. and for the proposed class shall be ignored.

13.3.4

1

M i

Yes

I

RR5

1 if non-use of explicit fiow control is proposed anti bit I of the additional
equals 1, it shall be treated as a protocol

j On receipt of the class and option parameter bits 4 to 1 if not
I__-._ meaningful I________ for the proposed class shall be Ignored

Whai action is stipportcd ---._ Index I--__ ! -_.____

on receipt of the follow Event

1 RR7
i-. _.._ I

A parameter defined in ISO/IEC 8073 (other than those covered above) and have an invalid value
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C.16.3

Actions

on receipt of an invalid or undefined

parameter

in a TPDU other than a CR TPDU

Event

i-----l
UIl Ul2

A parameter not defined in lSO/IEC protocol error

8073 shall be ?reated as a

-__-

-.
6X9

A parameter which has an invalid value as defined in iSO/IEC shall be treated as a protocol error

I 1 13.2.3 / ! _ .-. , -__ j 13.2.3 I 1
6.17.3

j

M

/

Yes

M

Yes

A TPDU received with a checksum UI3 (cloas1s~4 formula shall be discarded.

which does not satisfy the defined

/

M

/

Yes

1

i

--_--

C.17

Timers and protocol
are -- mandatoxif

parameters
________

The followin Index

class 4 is supported.

-l--~-; ReferencesF
1 72.2.1 M

SuppoT Yes i

t
-

TAl TA2 TA3

Tl' N I,_ W

PA4 i TA5

1

r-izil1 1 OTl 0T2 jD oes IUT support optiona! timer TS1 when operating in class O?

References

Status / / 0 0

r---j i

silppoil
No No

i / I

1 1

6.5.4 6.5.4

Yes Yes

1 D oes IIJT support optional timer TS7 when operating in class l?

Does IUT support !--?I16 OT7 OTB OT9 Does IUT support Does IUT support Does IUT support Does IUT support _---

optional optional optional optional optional

timer TSZ when operating timer TS2 when operating timer timer timer TS2 when operating TSZ when operating

in class O? in class l?

in class 3? in class 4?

IS 13919:
ISO/IEC

1994 8073 : 1992

Annex D
(Informative)

Checksum Algorithms
b) adding the value of CO to C7.

D.l

Symbols
symbols are used

D.3.4

Calculate

Xand CO

Y such that

The following

X=-C7+(L-n) CO. C7 variables used in the algorithms Y=Cl-(L-n+

1) CO X and Yin octets n and (n + 7)

i

is the number (i.e. position) TPDU (see 12.1); is the number (i.e. position) checksum parameter; is the length of the complete is the value parameter; is the value parameter. of the first

of an octet within

the D.3.5 Place the values respectively.

n

of the first octet of the NOTE - This algorithm calculates TPDU; octet of the checksum which is equal to zero, if the formulae in 6.17.3 are followed, since
L

L X

C7=,F,(L-i+

7)al

Y

of the second

octet

of the checksum j, (L

- i+ 7) ai= (L + 7) &a,-

,i,iai=

0

D.2
Addition

Arithmetic conventions
is performed in one of the two following modes:

D.4 Algorithm parameters D.4.1
Initialize

for

checking

checksum

a) module 255 arithmetic; b) ones complement arithmetic in which if any of the variables has the value minus zero (i.e. 255) it shall be regarded as though it was plus zero (i.e. 0).

CO and C7 to zero. each octet of the TPDU sequentially

0.4.2 Process from i= 7 to L by

a) adding the value of the octet to CO, then

Algorithm D.3 parameters

for generating

checksum

b) adding the value of CO to C7. 0.4.3 If, when all the octets have been processed, one or both of the parameters CO and C7 do not have the value zero, the checksum formulae in 6.17 have not been satisfied. NOTE - The nature of the algorithm is such that it is not necessary to compare explicitly the stored checksum bytes.

D.3.1 Set up the complete TPDU with the value checksum parameter field set to zero. D.3.2 D.3.3 a) initialize Process CO and C7 to zero. each octet sequentially from i=

of the

1to L by

adding the value of the octet to CO; then
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Annex E
(Informative)

State tables for operation of class 4 over connection-mode connectionless-mode network services

and

E.l

General

a)* the state of every network connection is known as being open or opening (i.e. a NCONreq has been issued and the NCONconf is awaited);
for each transport connection the transport entity b)' maintains the set of network connections to which the transport connection is assigned. A network connection in this set is either in the open or opening states; when a N-CONNECT confirmation, N-RESET c)' indication or N-DISCONNECT indication is received this event is associated with the transport connection if the network connection belongs to the set; when an N-DISCONNECT is received, the network d)' connection ceases to exist and is therefore withdrawn from the set. When a NCONconr is received the state of the NC becomes "open"; NOTE - This is not shown by an explicit action in the state table. Conversely adding a network connection to a set and setting its state to "opening" is shown by an explicit action. when the state goes back to CLOSED or REFWAIT state, it is assumed that all timers are stopped (if running), the count is set to zero and the set becomes empty;
e)'

This annex has been included as a guide for implementations which have been designed for operation over both the connection-mode network service and the connectionless-mode network service. The introductory annex as well. comments given in annex A apply in this

E.2

Conventions

Clause A.2 applies in this annex, except for item b) of A.2.3, in which the term "network connection" is to be extended to apply as well to the corresponding instance of communication over a connectionless-mode network service.

E.3
Clause annex.

Tables
A.3, including tables 4.1, A.2, A.3, apply in this

E.4

State tables for Class 4

f)* when a PDU is received the network connection which it has been received is assumed to be known; is used to 9)' the variable "current-NC" either the network connection on which a been received or the network connection been choosen for a new assignment (either one or a new one which is created); h) we also assume the following variables:

on

This clause incorporates all of clause A.6 with extensions to cover operation over connectionless-mode network services. This clause provides transport connection. a more precise description of a class 4

designate TPDU has which has an existing

Tables E.1, E.2, E.3 give the predicates, for class 4 respectively. Table E.4 connection. The following is the state table for

actions and notes

local-ref: the reference (local) of the TC is chosen when sending the CR or when accepting a CR; remote-ref: the reference of the remote entity is initially set to zero and initialised when processing the CC except if the CC is ignored. SRC-REF: designates received TPDU. DST-REF: designates received TPDU. the corresponding field of the

a class

4 transport

assumption

and notations over

are used: connection-mode

* : appropriate network service
l

only for operation

the corresponding

field of the fields

* : appropriate only for operation network service

over connectionless-mode

src-ref, dst-ref: designates of the sent TPDU.

the corresponding

count: designates the numbers been sent (retransmissions); 131

of times a TPDU has
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i) the data transfer phase is not completely in the state table but refers to the main text:

described

k)'

when a N-RESET indication RESET response is issued:

is received,

an N-

j)" a spontaneous event called "new network connection assignment" has been introduced. It may occur at any time provided Pl or P2 are true (see predicate table El) and the remote-ref is not zero (i.e. a CR TPDU has been received or a CC TPDU has been received and processed):

it is assumed that the connectionless-mode I)" network service when being used is continuously available. The operations resulting from signalled inaccessibility of the network are a local matter.

Table E.l - Predicates

for class 4

I

Name

I
T-CONNECT

Description request is acceptable. can be done to a suitable network

-

P2 P3 P4 P5

P6 P7 P8 P9 PlO Pll P99

opening). It is possible to open a new network connection. Local choice. _ A CR TPDU has never been sent. -The transport entity is the initiator and the set of network connections is now empty (i.e. a new assignment shall be done) or a new assignment is decided as a local choice. Local choice not to perform a new assignment if the set of network connections is empty (for closing state only). Count = maximum. Acceptable CR TPDU. Acceptable class 4 CC TPDU. Unacceptable class 4 CC TPDU. ~ CC TPDU not specifying class 4. Connection-mode network service being used.
natwork service is

NOTE - It is assumed that P99 = false implies only that the connectionless-mode being used.
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Table E.2 - Specific Name

actions

for class 4

Description Set reference timer Count = count + 1 Count = 0 Set retransmission timer Stop retransmission timer if running Set window timer Stop window timer if running Set inactivity timer Stop inactivity timer if running Set initial credit for sending according to the received CWCC TPDU Set initial credit for controlling reception according to the sent CR/CC TPDU P99: Send the CR TPDU if there is a network connection in the open state in the set: not P99: send a CR TPDU P99: Add the current network connection to the set, if not already included: not P99: no action P99: The current network connection is now in the opening state; not P99: no action P99: Send the CC TPDU if a network connection in the open state is in the set; not P99: send CC TPDU P99: Send the DR TPDU if a network connection in the open state is in the se!; not P99: send DR TPDU. In both cases, this DR TPDU is sent with src-ref = local-ref and dst-ref = remote-ref (may be zero) P99: Send the DR TPDU if a network connection in the open state is in the set; not P99: send the DR TPDU. In both cases, the DR TPDU is sent with src-ref = 0 and dst-ref = remote-ref Send a TPDU according to data transfer procedure See state table of the class specified in the CC TPDU (refer to data transfer) 4 P99: See state table of the class (refer to release procedure) send a DR TPDE if the class is not 0, otherwise issue a N-DISCONNECT request; not P99: send a DR TPDU Store request and exercise flow control to the user -Send a DR TPDU with src-ref field set to zero Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to zero P99: Send a DR TPDU with src-ref = local-ref and dst-ref = remote-ref (may be zero) if a network connection in the open state is in the set; not P99: send a DR TPDU with src-ref = local-ref and dst-ref = SRC-REF in CC TPDU

1I
--e [3] [4] (5. [6: 77: 18: :9:

I
[Z] [I21

1

I1 31 t

-7141
1151

[I61

[17] I 1 [ii]

-[201

1 I
[Z,

1

1231
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Table E.3 - Specific (' appropriate Name (I)* (2)' only when operating

notes for class 4 network service)

over connection-mode Description

(3)"

(4)'

( 1
(:)*

(7) (9) (9) . (10) (11)

(12)'

(
(::)*

1

(15)

is associated with this transport t connection. It is also possible to remain in the same state (Tl is still running) until: . a CC TPDU is received which performs a new assignment, . a new assiqnment is tried (spontanous event), . Tl runs outand the count is'equal to the maximal value. No new assignment was possible: if the set is empty, the transport entity waits until a new assignment is received, or can be locally performed (spontaneous event). It is also possible to perform a new assignment. (This may be done in triggering the event "new network connection assignment"). Not a duplicated CR TPDU. Since a new network connection is now assigned, it is recommended that the appropriate TPDU be sent on this network connection (if open) in order to make the remote entity aware of this assignment. It is also possible to allow the normal retransmission procedures to cause the TPDU to be sent; however the first TPDU available for sending should be sent on the new network connection. As a local choice it is also possible to apply the following: [0], TDISind. REFWAIT. Association to this transport connection is done regardless of the SRC-REF field. If SRC-REF is not zero, a DC TPDU is set back. At least an AK TPDU shall be sent if the transport entity is the initiator in order 1 to ensure that the responder will complete its three-way handshake. 1 If association has been made, and DST-REF is zero, then the DC TPDU contains a src-ref field set to zero. If the CLOSING state has been entered, coming from WFCC state, the remoteref is zero. The SRC-REF field of the CC TPDU is ignored (i.e. if the DR TPDU is retransmitted, it will be with the dst-ref field set to zero). If the CLOSING state has been entered, coming from WFCC state, the remoteref (which is zero) shall be set with SRC-REF in order to comply with the release procedure of the negotiated class. The DR TPDU may be either repeated immediately or when Tl will run out. If the set is empty, this event may be used as a criteria for triggering the event "new network connection assignment". Previously stored T-DATA or T-EXPEDITED-DATA requests are ready for processing according to data transfer procedures. See data transfer procedures. When an N-RESET indication is received, an N-RESET response has to be issued at once independent of the state automata.

1 Not possible as no set of network connections
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Table E.4 - Class 4 connection/disconnection
STAl EVENT REFWAI IT CLOSED

(1 of 2)
WFI-FIESP AKWAIT CLOSING

WFCC

T

OPEN

TCONreq

not PO: TDlSind CLOSED; PO and ((Pl and P99) or not P99): g~~,10,11 P99 an;d PO and not Pl and P2: [13,12.1.3,10: NCONreq WFCC; P99 and PO and (not Pl) and not P2: TDlSind CLOSED

CONresF -.DISreq P4: CLOSED; (not P4) and P3: WBCL; (not P4) and (not P3): [6.&4,3,2,1 ,151 CLOSING

,.

13,2,1,10,14] AKWAIT 1161 CLOSED

pgL'G51
JDISind
:I)

(1)

P99 and Pl: [121 WFCC; P99 and (not PI) and P2: 113,121 NCONreq WFCC; P99 and (not Pl) and (not P2): %!nd REFWAIT

P99 and 6: REFWAIT; P99 and (not P3) and Pl :

P99 and P5 and Pl,

P99: WFTRESP (4)

P99 and PE and Pl :

P99 and PS

[12,171(6)
OPEN; P99 and (not F;l) and P5 and P2: [13,12] NCONreq OPEN: P99 and (not Pl) and P5 ant I (not P2): OPEN (3); P99 and [not P5): 3PEN

(12,141(6)
AKWAIT; P99 and (not Pl) and P5 and ;23:.121 NCONreq AKWAIT; P99 and (not Pl) and P5 and (not P2): AKWAIT (3) P99 and (not P5): AKWAIT

Dl
REFWEAIT; P99 and (not P6) and P5 and Pl: [12,15] CLOSING (6) P99 and (not P6) and P5 and (not Pl) and P2: [13,12] NCONreq CLOSING; P99 and (not P6) and P5 and (not PI) and (not P2): ZLOSING 3); `99 and :not P6) and :not P5): ZLOSING `17)

[12,111
WBCL; P99 and (not P3) and (not PI ) and F&2] NCONreq WBCL; P99 and (not P3) and (not Pl ) and (not P2): :01 REFWAIT

RSTind ITreq EXreq

117)

117) +IPEN

1 17) F AKWAIT

2

135

IS 13919 ISO,lEC

: 1994
8073
: 1992

Table E.5 - Class 4 connection/disconnection STATE EVENT NCONwnf REFWAIT CLOSED WFCC zK----WBCL P99: ::CL (6) OPEN P99: [171

(2 of 2) WFTRESP P99: AKWAIT P99:

(11

(1)

ZR VVFCC(6)

WFTRESP ZWAIT P99 and Pl : VTRESP P99 and Pi and (not Pl) [13,121 NCONreq WFTRESP (6)

OPEN (6) P99 and Pl :

New Network Connection Assignmenl

P99 and Pl :

[12,171
OPEN (6); P99 and P2
and (not Pl): 113,121

gZW&)
P99 and'P2 and (not Pl): [13,121 NCONreq AKWAIT P7: [3,2,1,16] yg3s;g 4) not P7: ~~llxl~~~' 4)

NCONreq OPEN
Retranstimer

P7 and P3: [0] TDlSind REFWAIT; P7 and (not P3):

P7 and

;,,A,,: P7 and

r;32 1.15: Tbkihd CLOSING (14):
not P7: (16) (14) OPEN

p&l;1
CLOSING

(not P3): [3,2,1,15] CLOSING ;o;`;7

p:
_-InactivityTimer -___ ReferenceTime CR y~~w;1'dl*15:

CLOSING (7 CLOSED

Ml

not P8:

[121

[12,14]
AKWAIT

WFTRESP

CLOSED (P58)i

t9,;21
TCONind WFI-RESP
CC

;)R k--REFWAIT CLOSED
`9: 12,9,2,4,5,

299 and `11:

ER

REFWAIT CLOSED

7,171 rCONconf 9) OPEN; not P9 and lot P99) or P99 and `10): 12,4,3,2,1,23 TDlSind ZLOSING; `99 and Pl 1: 181 0] TDlSind 3EFWAIT
8) TDlSind 0] REFWAIT

191;

/not P99 and P9) or :P99 and ?ot Pll): :I 2,2,4,3,

(P99 and Pll): [191 (12); (not P99 and P9) or (P99 and not Pll):

1,151

1121

ZLOSING

CLOSING (11)

:!I

[12,6,%4X&
1,151 TDISinc CLOSING y$?J IO] x (10) rDlSind ZLOSED

REFWAIT :8) PI REFWAIT

DR

PI

[12,4,3,2,1, 15) TDlSind CLOSING DC (lo) M TDlSind REFWAIT

[o] REFWAIT

P21

[o] REFWAIT

REFWAIT CLOSED

REFWAIT
DC EA DTlAWED

REFWAIT CLOSED REFWAIT CLOSED REFWAIT CLOSED

IO] REFWAIT [12,8,7] OPEN (16) [12,8,7l OPEN (16) 136
1121CLOSING (13) [12] CLOSING (13)

[12,71 (15) (16)

